RUPSec : Extending Business Modeling and Requirements Disciplines of
RUP for Developing Secure Systems
Pooya Jaferian, Golnaz Elahi, Mohammad Reza Ayatollahzadeh Shirazi, Babak Sadeghian
Department of Computer Engineering and Information Technology
Amirkabir University of Technology
Tehran, Iran
{jaferian,elahi,ashirazi,basadegh}@ce.aut.ac.ir
Abstract
Nowadays, one of the main challenges facing computer
systems is increasing attacks and security threats against
them. Therefore, capturing, analyzing, designing, developing
and testing of security requirements have became an
important issue in development of security-critical
computing systems, such as banking, military and e-
commerce systems. For developing every system, a process
model is chosen. The Rational Unified Process (RUP) is one
of the most popular and complete process models which has
been used by developers in recent years. Our study and
analysis has shown that RUP should be extended for
developing security-critical systems. In this paper, we report
our work on extending Business Modeling and Requirements
disciplines of RUP for developing secure systems. We call
this extended version of RUP as RUPSec. The proposed
extensions in RUPSec are adding and integrating a number
of Activities, Roles, and Artifacts to RUP in order to capture,
document and model threats and security requirements.
1. Introduction
Security is an attribute of system that prevents the
system from revealing, changing and denying of
resource services and system information in an illegal
way. Generally three aspects of security are:
confidentiality, integrity and availability of service of
resources and information. To achieve these aspects
and develop a secure system, security services and
mechanisms should be considered [1].
One of the main phases in developing any
computing system is requirements engineering.
Requirements engineering is capturing, analyzing,
documenting and evaluating of requirements. In
requirements engineering, security is considered as a
nonfunctional requirement [2, 3, 4, 5], but in some
references security is classified as a functional
requirement [6, 7]. As it’s seen, it is naturally difficult
Proceedings of the 2005 31st EUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO-SEAA’05)
0-7695-2431-1/05 $20.00 © 2005 IEEE
to identify, apply, achieve and evaluate security
requirements [2].
Enforcing and managing security requirements
necessitates professional abilities and wide knowledge,
because systems are built to run under attacks of
unknown sources, therefore the security requirements
of them might be unknown. One of the challenges in
requirements engineering activities is capturing and
analyzing nonfunctional requirements such as security,
safety, reliability and usability requirements. Our
experience shows that often these quality attributes are
missed and are not captured by analysts. In practice, a
usual method in secure systems development is the
“penetrate and patch” approach. This means that
developers attempt to remove the vulnerable points
after the system is developed and attacks against the
system and defects occur. This approach usually
imposes heavy costs and defects on software projects.
Usually organizations try to document and record
their business security goals and requirements in
Security Policy Document. But there is no common,
clear and defined method to transfer the facts in the
Security Policy Document to precise and unambiguous
requirements and then including security requirements
in analysis, design, implementation and test phases of
software development process.
Researchers are trying to solve the mentioned
problems. The main focus of current works in this area
is using software engineering techniques to capture
and model security requirements [8,9,11] and common
threats [10]. Also, in [2] a new modeling language is
proposed for modeling security requirements [2].
According to the above discussion, it is reasonable to
integrate and coordinate secure software development
activities in a software process model [2].
In this work we have chosen Rational Unified
Process (RUP) as the basic process model for
extension. We believe that the RUP is one of the most
 complete and flexible process models. It is
configurable, easy to understand and follow and most
of the guidelines and activities of RUP is based on
software engineering related standards that have been
proposed by ISO and IEEE. We name the extended
RUP for developing security systems as RUPSec. The
aim of proposing the RUPSec is to define a software
process model in which security requirements are
considered in all phases of developing computing
system: business modeling, requirements, analysis and
design, implementation, and test.
In [12] the Requirements Discipline of RUPSec was
presented and in current paper proposed extensions in
Business Modeling and Requirements disciplines are
improved and presented. The main issues in these
extensions are: identifying security problems, threats
against the system and capturing, modeling and
evaluating security requirements. The secure software
development process model originated on RUP
(RUPSec) is developed based on case studies and
considering RUP weaknesses during developing case
study systems.
The arrangement of the paper is as follows. Section
2, provides a description of RUP as our basic process
model. Section 3 overviews the Security Requirements
in RUP. Section 4 is devoted to the new extended RUP
disciplines (RUPSec disciplines). In Section 5 the new
process model is evaluated. In Section 6, the new
process model is compared with related works and
similar models. The paper is concluded with Section 7
which contains brief recapitulation of the main points.
2. An Overview of RUP
Rational Unified Process (RUP) is an iterative and
incremental software engineering process. RUP has
four main phases: Inception, Elaboration,
Construction, and Transition. RUP has a number of
disciplines that are used in the mentioned phases. Each
discipline describes a set of activities and artifacts
around a group of common skills [7]. Main RUP
disciplines are: Business Modeling, Requirements,
Analysis and Design, Implementation, Test,
Deployment, Configuration and Change Management,
Project Management, and Environment. RUP is a
standards-based (IEEE and ISO software engineering
standard) yet configurable process environment that
can be tailored to suit the unique needs of each project.
3. Security Requirements in RUP
In RUP, the FURPS+ model (Functionality,
Usability, Reliability, Performance, Supportability, +
Proceedings of the 2005 31st EUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO-SEAA’05)
0-7695-2431-1/05 $20.00 © 2005 IEEE
(and others)) [6] is used to categorize requirements. In
this model, security requirements are classified in the
Functionality category. RUP just presents a set of
guidelines to capture and employ security
requirements. According to these guidelines the
following activities should be done:
- Identify the resources must be protected in system.
- Identify people and entities that can threats
system.
- Identify and categorize security requirements.
Captured requirements should be documented in
Software Requirement Specification. But it is not
mentioned that how these requirements should be
analyzed and modeled. Also, it is not clear how these
requirements are transformed and used in later phases
of software development.
In following sections, Business Modeling and
Requirement Disciplines of RUPSec are presented as a
solution to the declared problems.
4. Proposed Extensions
The aim of proposing RUPSec is to have a software
engineering process that guides developers to engineer,
design and implement security requirements in system
development process. RUPSec has been developed by
proposing new extensions in RUP Phases and
Disciplines. These extensions are in form of roles,
activities and artifacts. The extension plan of the
RUPSec is presented as figure 1.
Study
Study Security
Concepts
Choos e RUP as Analyze the other
bas ic proces s model contributions weaknes ses
Develope
RUPSec
Developing cas e
studies using RUP
Analyze RUP weakness es in
developing s ecure system s
[ Evaluation goals are not s atis fied ]
Adding and improving activities,
artifacts and a role into the RUP
Feature Based Evaluation of
extensions
[ Evaluation goals are satis fied ]
Figure 1. Extension plan of the RUPSec
 The Security Expert role is described in Table 1. 4.1. Extending Business Modeling Discipline
Table 2 shows an overview of the new artifacts in the
extended process model. Business Modeling is usually the starting point in
projects to learn about the target business, its goals,
Table 1. Security Expert Role and requirement. Generally over the normal usage, the
Role Security Expert purposes of this discipline in RUPSec are: identify
Role Type Additional Role security problems in the target business, capture
Tasks Consultation in security issues, Development of potential threats without considering how they will be
security test cases actually performed, and capture Security Policy of the
Skills Familiar with security concepts, threats and target business.
counter-measures, Familiar with system analysis
4.1.1. Improving “Maintain Business Rules”
Table 2. New artifacts in the RUPSec Activity. This activity is an improvement in Maintain
Artifact Name Description UML Model Business Rules activity in RUP. In this activity
Security Policy Security Policy, defines the - Business Process analyst role extracts Security Rules
security rules in the target to use them in “Organization Security Policy”
business. document. Security Rules clarify a set of “must” and
Threat Threat Specification, defines a -
“mustn’t” in organization and they can be declared in a
Specification set of threats against system
formal notation. In RUP a formal notation is proposed
Misuse Case Misuse case model, models <<misuse-case
to express the business rules. A number of its key
Model threats against each use case of model>>
system
words are:
Security Use Security Use Case model, <<security IF, ONLY IF, WHEN, THEN, ELSE, IT MUST
Case Model models the security solution for use-case ALWAYS HOLD THAT, IS CORRECTLY
each misuse case model>> COMPLETED
Misuse Case Misuse case shows actions that <<misuse To express the security rules about permission to
threaten the system case>> access the service of system resources, we have added
Misactor Misactor is the actor which <<misactor>> two new key words to mentioned notation:
threatens the system by using a HAS RIGHT / HAS NOT RIGHT
misuse case. Security Rules will be used to extract Security
Security Use Security Use Case prevents one <<security >> Policy by the following.
Case or more misuse cases.
4.1.2. Defining Security Policy: a new activity in
In table 3 the new activities of the RUPSec and in Business Modeling Discipline. This activity does not
table 4 the improved activities of RUP are presented. exist in RUP, but in order to capture stakeholders
requests in security aspects of a system and their
Table 3. New Activities in the RUPSec desired degree of security, is added to RUPSec
Activity Name Resulting Artifact activities. Output of this activity is called “Security
Define Security Policy Security Policy Policy Document”. If there is a Security Policy in an
Find Misactors and Misuse Cases Misuse Case Model organization it would be improved during Business
Finding System Threats Threat Specification Document Modeling Discipline. This document is prepared by the
Refine Misuse Cases and Finding
Security Use Case Model Security Expert and Business Process Analyst Roles.
Security Use Cases
This usage of this document is discussed in
Requirement Discipline. Answering the below
Table 4. Improved RUP activities in the RUPSec questions would define the Security Policy:
Activity Name Description
x Which resources and data should be protected in
Maintain Business Rules Maintain Security Business Rules
system?
Find Business Actors and Use Document security aspects of
Cases Actors and Use Cases x What is the right treatment of system resources?
Find Business Workers and Define access level of workers to x Who has permission to use the system?
Entities entities x What are the responsibilities and rights of system
Define Automation Capturing Business Security users and administrators?
Requirement Requirements from Security Policy x Who offers and invalidates the permissions in the
Detail the Software system?
Refine Security Requirements
Requirements

Proceedings of the 2005 31st EUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO-SEAA’05)
0-7695-2431-1/05 $20.00 © 2005 IEEE
 x What events and people threaten the system security
(that system should be protected against them)?
The answers to the aforementioned questions
specify the system threats. These threats are expressed
independent of how a system works. For example in a
sales system, whether the system works on web or in
traditional markets, theft threatens the system. Security
Policy is documented based on stakeholder’s needs
and security threats in the system. Commonly, this
document is expressed in natural language.
After answers of the questions are declared by
system owners and customers collaborating with
security expert, Security Policies should be
documented in a template. The Security Policy
template contains a table, which defines the type of
access and people hierarchy access in the system or
related people outside the system. For example, Table
5 specifies the manager, assistant and customers
responsibilities and access type for sale system as case
study.
Table 5. Sale system access types
person name Responsibility data access
type
Manager Organize manager
2
Assistant meetings and visitors
manager Lead the organization 1 introduced. Workers in the system perform the
Receive services from
Customer 3
business system
Table 6 specifies the resources that each access type
has the right to use. For example, the manager with
access type 1 has access to all system resources but the
customer only has the right to access his/her own
information. Also the access types can be defined in a
hierarchical way.
Table 6. Sale system rights of access types
Access level personnel information sales
information
1 + +
2 + -
3 - -
4.1.3. Improving “Find Business Actors and Use
Cases” Activity. In this activity of RUPSec, in
addition to the usual description in RUP, it is
suggested that Security Expert documents the below
points. The goal is to document more information
about security aspects of Actors and Use Cases:
x Specify the actor’s skill, knowledge, and
information about computer security and attacks.
x Specify the actor’s benefits to attack the system.
x Declare the threats that the actor has the potential
to perform
x Declare the risk of threats
x Assert the threats that a use case directs to the
system
4.1.4. Improving “Find Business Workers and
Entities” Activity. This activity is an improvement on
“Find Business Workers and Entities” activity. In this
improvement an extended Artifact of RUP is
processes inside the system or organization. Business
Workers and Actors deal with information, resources
and services of system, and should be settled in a
security type or level. This security access level is
defined in Security Policy and in this phase is modeled
in the Business Entity Diagram. To specify the detail
of an access type or level a number of Stereotypes are
defined in this diagram. These stereotypes and their
meaning are expressed in Table 7, which can be
combined together.

<<modify,add,delete>> <<read>>

<<modify,add,delete>> Account
Accountant Customer
<<modify,add,delete>>
1 0..*
<<Read>> Bill

<<read>>

<<modify,add,delete>> Order
Seller Delivery
1..*
Product
Figure 2. Business Workers and Entities Diagram

Proceedings of the 2005 31st EUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO-SEAA’05)
0-7695-2431-1/05 $20.00 © 2005 IEEE
 These stereotypes declare that each person has the
right to do which functionality on system data. For
example, in Figure 2, the seller has the right to change
the information about the products and add or delete
some products, but the seller can only read the
information about customer's orders.
Table 7. Business Workers and Entities Stereotypes
Stereotype Usage
<<add>> Only the permission to add data
<<read>> Only the permission to read the data.
<<delete>> Only the permission to delete data
Only the permission to modify and alter
<<modify>>
data.
4.1.5. Capturing Business Security Requirements
from Security Policy: Improving “Define
Automation Requirement” Activity. After
completing Security Policy and interviewing with
system owners and stake holders, a number of general
security requirements are captured by Business
Designer and Security Expert roles. These
requirements are documented in Supplementary
Specification.
4.2. Extending Requirements Discipline
The goal of the Requirements Discipline in the RUP
is to establish and maintain agreement with the
customers and other stakeholders on what the system
should do. In this discipline system developers gain a
better understanding of the system requirements and
boundaries of the system are defined. In addition to
common purposes, the purpose of this discipline in
RUPSec is: to capture and model security threats
against the system, to propose security solutions for
the threats and to elicit security requirements of the
system.
4.2.1. “Find Misactors and Misuse Cases”: A New
Activity in Requirements Discipline. RUP is a use-
case driven approach for developing software [7].
Therefore, we suggest using Misuse Cases to find
threats and security requirements. As the functional
requirements are described via use-cases, the activities
that yield a security threat can be expressed as misuse
cases. Therefore, a new activity named "Finding
Misactors and Misuse-Cases" is added to RUP as an
independent activity in the RUP's "Define the System"
workflow detail.
In this activity, Along with finding use cases and
actors, Misuse cases and Misactors should be
identified. Misactor is an actor who threatens the
Proceedings of the 2005 31st EUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO-SEAA’05)
0-7695-2431-1/05 $20.00 © 2005 IEEE
system and misuses the system through a misuse case.
While the purpose of use cases is to describe the
customer goals, the purpose of misuse case is to model
security threats. In this case actor or external system is
replaced by a Misactor who threatens the system.
In the next steps misuse cases will form a basis for
eliciting security requirements and security use cases.
The inputs to this activity are "Threat Specification
Document" and "Security Policy" and the output
artifact is Misuse case model. This output will be used
in Analysis and Design Discipline and Designing Test
Scenarios. The System Analyst role is responsible for
performing this activity.
4.2.2. Finding System Threats: A New Activity in
Requirements Discipline. Finding Misuse cases and
threats is an iterative activity. In other words the
threats are completed with respect to Misuse cases and
Misuse Cases are found and refined by means of
threats. The Security Expert finds the threats against
the system based on the experiences and knowledge of
past projects. The Security Expert also presents a
general solution to counter each threat. The Misuse
Cases will be extracted using these threats and this
process continues iteratively.
With respect to the above discussions, a new activity
called “Finding System Threats” is added to “Define
the System” workflow detail of RUP. The inputs to
mentioned activity are "Misuse case Model" and
"Security Policy". The threats that are identified by the
Security Expert are documented in “Threat
Specification Document” as output of the activity and
is used in Analysis and Design and Test Disciplines.
The “Threat Specification Document” is used by the
System Analyst to extract the Misuse-Cases. Also it is
recommended to record the “Threat Specification
Document” in "Threat Repository" for future uses.
In Figure 3, the use cases and Misuse-Cases of the
sale system are presented. The use cases, which are
identified by <<misuse case>> stereotype, illustrate
threats against the system. These threats take place
during the flow of use cases and their occurrence is
illegal. Therefore, the dependency between use case
and related Misuse-Case should be specified by
<<extend>> relationship between use cases.
4.2.3. Refine Misuse Cases and Finding Security
Use Cases: A New Activity in Requirements
Discipline. In order to find security requirements, we
have added a new activity to the RUP, which is called
"Refine Misuse cases and finding Security use cases"
as an independent activity in “Define the system”
workflow detail.
 <<extend>>
Search and choose products
<<extend>> Pay for Order
<<extend>>
Order products
Customer
<<extend>>
Supply accounts <<extend>>
System Manager
Manage customer accounts
Figure 3. Misuse Case of Sale System
In this activity, the system analyst studies “Misuse case
Model” and “Threat Specification Document” to
capture security use cases. In current activity, the
misuse case flow of events is defined precisely. After
that the system analyst specifies the solutions to
confront the threats with respect to Threat
Specification Document. These solutions are called
"Security Use cases" and they should be described and
documented. In current activity, the system analyst
should avoid interfering technological aspects to select
and describe security use cases. For example, is this
step, we should avoid offering solutions such as using
cryptographic algorithms, passwords and etc, because
using specific technology as security use case will
restrain finding better solutions in selecting appropriate
architecture and designing the system.
To document a Security Use-Case, the following
points should be considered:
x Related threats should be specified.
x For each Security Use-Case, the flow of events
should be studied in the three following viewpoints:
System, Normal Actors and Misactors activities.
In this approach the system activities to provide the
required security are captured and recorded as security
requirements. In the Security Use-Case Description
table which is presented in [9], the post condition of
each Security Use-Case is considered as a general
security requirement. The purpose of mentioned
requirement is to counter the related misuse case.
Usually, security use cases can be classified into
several categories [9]. Also each category may have
different paths [9]. To obtain security requirements
from security use cases, each use case path should be
analyzed independently and security requirements for
each path should be extracted.
Proceedings of the 2005 31st EUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO-SEAA’05)
0-7695-2431-1/05 $20.00 © 2005 IEEE
<<misuse case>>
Disable the site
<<misactor>>
<<misuse case>>
External attacker
Pay for orders using
customer accounts
<<misuse case>> <<misactor>>
Supply or charge account
Inside organization
In the use case diagram of Figure 4, for each
Misuse-Case, we can present a number of solutions.
These solutions are modeled by security use cases.
Security Use-Cases are denoted by <<security>>
stereotype. The dependency between Security Use-
Case and Misuse-case is defined by <<prevent>>
stereotype. This type of dependency specifies that
security use case prevents the occurrence of Misuse-
Case. In table 8, requirements discipline's proposed
stereotypes are overviewed.
Table 8. Requirements Discipline's Stereotypes
Stereotype Application
<<misactor>> The Actor, Who misuses the system.
The use case which shows the misuse of
<<misuse
system and is a potential threat against the
case>>
system.
<<security>> The use case which prevents a misuse case.
Dependency, which specifies the security
<<prevent>> use case that prevents a specific misuse
case.
4.2.4. Improving "Detail the Software
Requirements" Activity. The system requirements
will be obtained by describing each Security Use-Case.
These requirements usually can be found in "System
Actions" column (in security use case description table
[9]) and Security use case post-condition.
The mentioned system requirements should be
categorized and documented. Therefore, in "Detail the
software requirements" activity of the RUP, the
Requirement Specifier should document the security
requirements in "Software Requirement Specification"
document according to the requirement's type. Security
requirements will form a basis for “Analysis and
Design” discipline along with security use case model.
 <<Prevent>>

<<misuse case>>
Search and choose products <<security >>
System protection Disable the site

<<include>>

Customer Order products Pay for Order <<misuse case>>

<<misactor>>
<<include>> Pay for orders using customer External attacker
accounts
<<include>> <<Prevent>>
Supply accounts

<<include>> <<Prevent>>
System Manager
<<misuse case>> <<misactor>>
Manage customer accounts <<security>>
Inside organization
Access Control Supply or charge account
attacker
Figure 4. Security Use Case Diagram For Sales System

5. Evaluation of Presented Extensions common process models such as RUP. Therefore, they
can be used in any type of projects.
There are various methods to evaluate a software Suitability of Extensions: The proposed extensions
development process model. Two common ways are don’t diverge from RUP’s flow of activities and
evaluation based on case studies and Feature Based disciplines. The developers who are familiar with RUP
Evaluation. To evaluate proposed extensions, we use can use RUPSec without intensive training. The
the criteria introduced in [13] for evaluating software resulted artifacts of extended disciplines are used in
engineering methodologies and evaluate our extension analysis and Design, Implementation and Test
based on a subset of these criteria. Discipline that are discussed in further works.
Expressiveness: a process model should be
introduced in such a way to cover various aspects of a Table 9. Requirements Discipline's Stereotypes
system. Whereas threats and security aspects like Aspect RUPSec RUP
confidentiality, integrity and availability are not Organization Documented in Security Is not
mentioned in RUP, in this paper some solutions are Security Policy Policy documented
presented for modeling and documenting these aspects. Threats against Modeled and documented Is not
the system in Threat Specification and documented
In Table 9, these solutions are compared to RUP.
Misuse Case document
Preciseness: a Process model should be
Security Modeled and documented Is not
unambiguous, that it would be possible to use it in a aspects of using Security Use Cases documented
correct way. In the RUPSec inputs, outputs, time to do, system
related discipline and role are declared and integrated
with RUP. This prevents ambiguity in extensions.
Accessibility : a process model should be practical 6. Compare to Related Works
for various groups of developers with different skills
and level of knowledge. As RUP is used widely and In previous sections RUPSec and its improvements
UML is a universal modeling language, RUPSec is on RUP are introduced. Many aspects, phases and
based on RUP and modeling language is UML. activities in the RUPSec are discussed in
Therefore, using the extensions is easy for developers [2,8,9,14,15,16,17,18] too, but in this paper we have
who are familiar with RUP and UML. investigated to integrate existing attempts and works in
Portability: a process model shouldn’t depend on the framework of RUP.
implementation language, special technology or In [15], the presented process model is not based on
architecture. In presented extensions, it is emphasized a reference process model. As in [15] activities,
on using standard modeling languages like UML and artifacts, and roles aren’t specified in detail, developers
have to integrate the mentioned process models with

Proceedings of the 2005 31st EUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO-SEAA’05)
0-7695-2431-1/05 $20.00 © 2005 IEEE
 their own process model. In this paper, all extended
activities and artifacts are incorporated with RUP.
In [14], use cases are extended to cover security
requirements, but it is not discussed for what threats
the system should be protected. In [17] the aspect of
Abuse Case is introduced but no way for including
these threats in analysis and design model is not
suggested. In [9] more than modeling Misuse Cases, a
number of Security Use Cases are assigned to normal
Use Cases to protect the system against the threats. In
the present paper we have tried to eliminate the
weaknesses in [9, 14, 17] using Misuse Cases and
Security Use Cases, Threat specification and Security
Policy.
One of the similar attempts to RUPSec is CLASP.
CLASP(Comprehensive, Lightweight Application
Security Process) provides a well-organized approach
for moving security concerns into the early stages of
the software development lifecycle [22].
7. Conclusion and suggestions for further
works
In this paper some extensions on Business modeling
and Requirement discipline of RUP were presented.
These extensions include adding activities, artifacts,
and roles to RUP or improving them. In current stage,
these extensions don’t cover the whole RUP
disciplines and in the next researches we will use the
results to more disciplines. In the next phases of work,
captured Misuse Cases will be realized in analysis and
design discipline. System attacks are identified
whereas they are realized. Attacks will be realization
of system potential threats considering the technology
of implementation. Security Use Cases will be
realized and used to specify Analysis Mechanism and
design against threats. Also Misuse Cases will be used
in test phase to generate Test Cases.
References
[1] M. Bishop, Computer Security, Art & Science, Addison-
Wesley, First Edition, 2002
[2] J. Jürjens. Secure Systems Development with UML,
Springer-Verlag, December 2004.
[3] S. Doshi, “Software Engineering and Security: Towards
Architecting Secure Software”, a graduate term paper for
ICS 221, Seminar in Software Engineering, University of
California, Irvine, 2001.
[4] L. Chung, and B. A. Nixon, “Dealing with non-functional
requirements: three experimental studies of a process-
oriented approach”, Proceedings of the 17th international
conference on Software engineering, Seattle, Washington,
United States, 1995, pp 25 – 37.
Proceedings of the 2005 31st EUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO-SEAA’05)
0-7695-2431-1/05 $20.00 © 2005 IEEE
[5] B. Paech, A. H. Dutoit, D. Kerkow, and A. V. Knethen,
“Functional requirements, non-functional requirements, and
architecture should not be separated”, 8th International
Workshop on Requirements Engineering: Foundation for
Software Quality, Essen, Germany, 2002
[6] R. Grady, Practical Software Metrics for Project
Management and Process Improvement, Prentice Hall, 1992.
[7] P. Kruchten, The Rational Unified Process: An
Introduction, Third Edition, Addison-Wesley, 2003.
[8] D. G. Firesmith, “Engineering Security Requirements”,
Journal of Object Technology, Vol. 2, No. 1, January-
February 2003.
[9] D. G. Firesmith, “Security Use Cases”, Journal Of Object
Technology, Vol. 2, No. 3, May-June 2003.
[10] R. J. Ellison, R. C. Linger, and A. P. Moore, “Attack
Modeling for Information Security and Survivability”
CMU/SEI-2001-TN-001, 2001
[11] J. Barcalow, and J. Yoder, “Architectural Patterns for
Enabling Application Security”, Proceeding of The 4th
Pattern Languages of Programming Conference, Allerton
Park, Monticello, Illinois, USA, 1997. pp. 40-51
[12] M.R. A. Shirazi, P. Jaferian, G. Elahi, H. Baghi, B.
Sadeghian, “RUPSec : An Extension on RUP for Developing
Secure systems – Requirements Discipline”, Proceedings of
The Second World Enformatika Congress (WEC'05),
Istanbul, Turkey, 2005, pp. 208-212
[13] O. Shehory, and A. Sturm, “Evaluation of modeling
techniques for agent-based systems”, Proceedings of the 5th
international conference on Autonomous agents, Motreal,
Canada, 2001, pp. 624-631.
[14] G. Popp, J. Jürjens, G. Wimmel, and R. Breu, “Security-
Critical System Development with Extended Use Cases”,
Proceeding of 10th Asia-Pacific Software Engineering
Conference, Chiang Mai, Thailand 2003, pp 55-60.
[15] R. Breu, K. Burger, M. Hafner, J. Jürjens, G. Popp, G.
Wimmel, and V. Lotz, “Key Issues of a Formally Based
Process Model for Security Engineering”, Proceedings of the
16th International Conference on Software & Systems
Engineering and their Applications (ICSSEA03), 2003.
[16] P. Devanbu, and S. Stubblebine, “Software engineering
for security: a roadmap”, In A. Finkelstein, editor, The
Future of Software Engineering, ACM Press, 2000.
[17] J. McDermott, and C. Fox, “Using Abuse Case Models
for Security Requirements Analysis”, Proceedings of the 15th
Annual Computer Security Applications Conference,
Washington, DC, USA, 1999.
[18] G. Petterson, “Collaboration in a Secure Development
Process – Part I”, Information Security Bulletin, June 2004.
[19] R. Breu, K. Burger, M. Hafner, and G. Popp, “Towards
a Systematic Development of Secure Systems”, Information
Systems Security Journal, Volume 13, Number 3,
July/August 2004, pp. 5-13.
[20] D. Basin, J, Doser, and T. Lodderstedt, “Model driven
security for process-oriented systems”, Proceedings of the 8th
ACM symposium on Access control models and technologies,
Villa Gallia, Como, Italy, 2003, pp. 100-109.
[21] R. Anderson, Security Engineering, a guide to building
dependable system, Wiley, 2001.
[22] The CLASP Application Security Process, Secure
Software Inc document, 2005.