SIREN
“SImple REuse of software requiremeNts”
Edwin Meulendijks (3279324)
Method Engineering, Group 2
Utrecht, 25-03-2011
1
1
Introduction
According to Toval, Nicolás, Moros and García (2002) information system security issues are often
overlooked and only thought of, after the development process has been completed. Instead of that,
security issues should be considered from the beginning and in particular in the system requirements
specification phase.
Ambrosio Toval, Joaquín Nicolás and Begoña Moros are all members of the Software Engineering
Research Group in the Department of Computing and Systems at the University of Murcia. Toval is
the head of the Software Engineering research section. Fernando García worked at Innosec, which
was the Innovative Secure Communication Incorporation, located in Madrid, Spain. He seems to be
the only person to have a business-related background.
They present with the SIREN approach, shown in figure 1, a practical method to elicit and specify the
system and software requirements. Toval et al. (2002) provide five examples of why the privacy
issues should be taken into account more structurally. Information systems are vulnerable to the
following threats: viruses, the unacceptable employees use of the internet, not observing personal
data privacy laws, strikes, and loss of key personnel. A recent survey on 539 UK organizations shows
that 90% of all large (more than 250 staff) and 74% of all small UK businesses had a malicious security
incident in the last year (PricewaterhouseCoopers, 2010). In 2008 this was only 35% for the overall
UK organizations. Since 2004 this number was declining, but now, that trend is reversed dramatically.
Reusable
Repository
Repository Improvement
Requirements
Selection
Specific
Requirements
Elicitation
Analysis
and
Negotiation
Validation
Documentation
Stakeholders
Next phases: analysis,
design, implementation, ...
Analysts
Figure 1: SIREN approach for requirements reuse simplified (Toval et al., 2002).
2
This SIREN (SImple REuse of software requiremeNts) method includes a reusable requirements
repository, a spiral process model and a set of requirements documents templates. The reusable
requirements repository contains all the security requirements for specific domains and profiles from
MAGERIT (Metodología de Análisis y GEstión de RIesgos del MinisTerio de Administraciones
Públicas), which is the Spanish public administration’s adaption of CCF (Common Criteria
Framework). CCF is the ISO 15408 standard for computer security, which helps to specify the security
requirements and security attributes of products, after which it helps to determine if those are met
(Mellado, Fernández-Medina, & Piattini, 2006).
The spiral process model is based on a model proposed by Kotonya and Sommerville (1998).
According to them, RE (Requirements Engineering) consists of the following phases: requirements
elicitation, requirements analysis and negotiation, requirements documentation, and requirements
validation. Toval et al. (2002) adapt this model by dividing the elicitation phase into two activities: a
‘requirements selection’ activity, and a ‘specific requirements elicitation’ activity.
There are six clear steps in the model by Toval et al. (2002). These are:
1. Requirements selection
2. Analysis and negotiation
3. Documentation
4. Validation
5. Specific requirements elicitation
6. Repository improvement
There is no set order in which these steps are executed. It is a continuous process, which may be
ended when the stakeholders and analysts decide the selected requirements are valid and cover all
the important aspects of the new system (Toval et al., 2002). One can for example move on to the
design or implementation phase.
The third part of the model are the requirements documents templates. Those templates are used to
describe the requirements that are elicited, analyzed, negotiated, documented or validated. Toval et
al. (2002) propose in their paper a hierarchy in which these requirements documents are to be
categorized. These five types of documents are: SyRS (System Requirements Specification), SRS
(Software Requirements Specification), SyTS (System Testing Specification), STS (Software Testing
Specification), and IRS (Interface Requirements Specification). The templates conform to the IEEE
requirements specification standards (Gutiérrez, Moros, Toval, Fernández-Medina, & Piattini, 2005).
3
2
Example
One wants to create a new information system (IS). To do this, different requirements have to be
selected. These can be gained from the reusable requirements repository, which contains the
MAGERIT security standard requirements. One can also select empty templates, to set specific
requirements for the new system, or use earlier validated requirements documents. After this phase,
one will have filled-in templates with reused requirements. Examples of such requirements are
shown in table 1. A template for this table can also be found in the appendix.
Requirements
Explanation
SyRS 562S98
USB devices may only be used for business matters and have to secured with a
password protection.
SyRS 456S34
Users of the information system have to sign an agreement to only use the
resources of the system for purposes related to the company.
SRS 3531S1
The operating systems have functioning virus scanners to prevent viruses to enter
the system.
SRS 6576S11
The used operating system should keep a detailed list of users that have access to
the system. It must be possible to ban persons on this list from further access.
IRS 45S567
The system must have a white background with a black font color.
Table 1: Examples of system (SyRS), software (SRS), and interface (IRS) requirements.
The specific requirements elicitation will supply, on the other hand, the informal requirements for
the new system. We then have the filled in templates and the informal requirements. They are
analyzed and negotiated. This will result in agreed requirements, which are then documented. After
that, they are validated and put into the reusable repository. They can also directly form the basis for
the ‘requirements selection’ and ‘specific requirements elicitation’ phases.
Once the validated requirements documents are considered to be complete enough, the
development process can begin. One can start designing a system which for example has system
locks for documents and diskettes, a password system for authorizing users, and a system which
checks the passwords for their quality. They should for example contain at least six characters, have
at least both one numeric and alphanumeric character, and it should be changed every thirty days for
general users and every ten days for users with privileges.
4
3
Process-deliverable diagram
The process-deliverable diagram (PDD) is shown on the following page (figure 1). It is the PDD of the
SIREN method as proposed by Toval, Nicolás, Moros, and García (2002). One small note has to be
made: the closed concept ‘VALIDATED REQUIREMENT’ has the same structure as the ‘DRAFT
REQUIREMENT’. The PDD is a method description technique proposed by Weerd and Brinkkemper
(2008).
The process is started by selecting requirements. This is done by studying threats, estimating the
risks associated with those threats and determining the countermeasures to those risks. The
stakeholders as well as the analysts are involved in this activity (Toval et al., 2002). After this
selection, one can move on to the ‘analyze and negotiate requirements’ activity if all threats are
covered by the selected requirements.
If this is not the case, specific requirements have to be elicited. This means that the repository did
not contain all the necessary requirements to cover all the risks. This activity too, is executed by
stakeholders and analysts. Once all requirements seem to be elicited the next activity will be to
analyze and negotiate those requirements.
In the ‘analyze and negotiate requirements’ activity both the stakeholders and analysts discover the
problems with certain specified or selected requirements, and remove redundancies and
inconsistencies. After these sub-activities are performed, agreement is reached on the changes to be
made (Toval et al., 2002). From this, the agreed requirements are identified.
It is then time to document those requirements. This is done by specifying the system, software, and
interface requirements and the system and software tests (Toval et al., 2002). This activity is solely
executed by the analyst.
The stakeholders and analysts then together validate all the requirements that were selected,
elicited, analyzed and documented. If the requirements are valid, they will be used to improve the
repository and one can ‘complete’ the method. Improving the repository is done by the analyst. If the
requirements are not valid, other requirements have to be selected from the repository or new
requirements can be elicited in the ‘elicit specific requirements’ activity.
5
Figure 2: Process-deliverable diagram of the SIREN method.
6
3.1
Activity table
Activity
Sub-Activity
Description
Select requirements
Study threats
Estimate risks
The threats to the assets of the system are studied.
The risks are estimated depending on the previously
mentioned threats.
The countermeasures are determined to deal with
the risks that were identified.
Based on those countermeasures, one selects the
suitable requirements from the reusable repository.
Requirements that are specific to the subject in
question are elicited and formulated by means of
informal requirements.
Problems with the system requirements are
discovered.
Redundant requirements are eliminated.
The inconsistent requirements are removed.
The stakeholders and analysts reach an agreement on
the changes that need to be made.
The agreed requirements are identified.
Dertermine
countermeasures
Select requirements
Elicit specific
requirements
Analyse and negotiate
requirements
Document requirements
Discover problems
Remove redundancy
Remove inconsistency
Reach agreement on
changes
Identify agreed
requirements
Specify system
requirement
Specify system tests
Specify software
requirements
Specify software tests
Specify interface
requirements
Document
requirements
Validate requirements
Improve repository
The system requirements are specified by the
analysts.
The system testing specification is formulated.
The software requirements are specified.
The corresponding software testing specification are
listed and connected to the software requirements.
The interface requirements are specified.
The analysts document the requirements in the
formal structure.
The requirements that were documented in the
previous step are validated by the stakeholders and
analysts. If they can’t be validated, one returns to the
‘select requirements’ or ‘elicit specific requirements’
activity.
If the requirements are found to be valid they are
stored in the reusable repository. This improves the
repository.
Table 2: Activity table of the PDD of the SIREN method.
7
3.2
Concept table
Concept
Description
REUSABLE REPOSITORY
A RESUABLE REPOSITORY contains all the requirements that have already been
validated and stored (Toval et al., 2002).
A THREAT is what describes the dangers to the assets of the system (Toval et
al., 2002).
The RISK is estimated by looking at the threats to and vulnerabilities of the
assets (Toval et al., 2002).
A COUNTERMEASURE defines how the risks will be covered and managed
(Toval et al., 2002).
A VALIDATED REQUIREMENT has passed all the steps of the method and will
be stored in the requirements repository (Toval et al., 2002).
AN INFORMAL REQUIREMENT is created in the ‘Elicit specific requirements’
phase. It is a problem specific requirement which is not available in the
repository (Toval et al., 2002).
PROBLEMS that need to be solved by identifying suitable requirements (Toval
et al., 2002).
A REDUNDANT REQUIREMENT is one that is already covered in another
requirement (Toval et al., 2002).
An INCONSISTENT REQUIREMENT is one that cannot coexist with another
requirement, because they have conflicting needs (Toval et al., 2002).
The CHANGE defines what needs to be changed to identify the agreed
requirements (Toval et al., 2002).
AGREED REQUIREMENTS are formed in the ‘Analyze and negotiate
requirements’ phase. They contain what the stakeholders and analysts agreed
on (Toval et al., 2002).
A SYSTEM REQUIREMENT SPECIFICATION is the format for the description of
the functions and performance of a system and the constraints it places on the
information flows. It is based on IEEE standard 12207.1 and 1233 (Toval et al.,
2002).
The SYSTEM TESTING SPECIFICATION contains the testing criteria – if it fulfills
the requirement – for each system requirement specification (Toval et al.,
2002).
In the SOFTWARE REQUIREMENTS SPECIFICATION the functions and
performance of particular software are defined (Toval et al., 2002). This
specification is based on IEEE standard 830 and the VOLERE template
(Robertson & Robertson, 1999).
The SOFTWARE TESTING SPECIFICATION contains the testing criteria – if it
fulfills the requirement – for each software requirements specification (Toval
et al., 2002).
An INTERFACE REQUIREMENTS SPECIFICATION is the format for the
requirements related to the interfaces of the software. It is based on IEEE
standard 830 and the VOLERE template by Robertson and Robertson (1999).
A DRAFT REQUIREMENT is the documented form of an agreed requirement.
They consist of five specification document types (Toval et al., 2002).
THREAT
RISK
COUNTERMEASURE
VALIDATED REQUIREMENT
INFORMAL REQUIREMENT
PROBLEM
REDUNDANT REQUIREMENT
INCONSISTENT
REQUIREMENT
CHANGE
AGREED REQUIREMENT
SYSTEM REQUIREMENT
SPECIFICATION
SYSTEM TESTING
SPECIFICATION
SOFTWARE REQUIREMENTS
SPECIFICATION
SOFTWARE TESTING
SPECIFICATION
INTERFACE REQUIREMENTS
SPECIFICATION
DRAFT REQUIREMENT
Table 3: Table of concepts of the PDD of the SIREN method.
8
4
Related literature
The SIREN approach is based on the REPM (Requirements Engineering Process Maturity) model by
Sommerville and Sawyer (1997), in which they define a set of good practices in RE and allow
organizations to be assessed at three levels. These levels are:
1. Initial
There are no requirements engineering processes within the organization.
2. Repeatable
Within the organization, standards for requirements documents and descriptions are in place.
Policies and procedures for managing requirements have also been introduced.
3. Defined
The requirements engineering process is well-defined within the organization. There is also a
process improvement program available to objectively look at new tools and techniques.
This guide by Sommerville and Sawyer (1997) is also the basis for the spiral process model which was
described earlier in this paper.
The SIREN method was developed because other methods missed some essential parts to combine
RE with security. For example, SSADM (Structured Systems Analysis and Design Method) combined
with CRAMM (CCTA Risk Analysis and Management Method) and Métrica 3 combined with MAGERIT,
both do not provide a reusable requirements repository (Toval et al. 2002). This is also the case for
the PFIRES (Policy Framework for Interpreting Risk in eCommerce Security), which is a non-standard
framework that assesses risk in e-commerce systems. This method also fails in translating the
security recommendations into requirements.
So, looking closer at the SIREN method, the general idea is based on REPM, the security requirements
are based on MAGERIT, which in its place is based on the ISO 15408 standard Common Criteria
Framework (CCF). The spiral process model is adapted from REPM too, the requirements documents
templates are based on IEEE standards (The Institute of Electrical and Electronics Engineers, 1998)
and on the VOLERE template proposed by Robertson & Robertson (1999).
A paper in which different RE techniques and methods are described is ‘A systematic review of
security requirements engineering’ by Mellado, Blanco, Sánchez and Fernández-Medina (2010). They
compare 22 initiatives for RE, including the SIREN approach by Toval et al. (2002). They compare
them based on technical and specification criteria. The SIREN method scores a ‘*’ for ‘yes’ on all
criteria, except for ‘external validation support’, ‘complete standards integration’, and ‘complete
support for other development stages’, on which it scores a ‘p’ for ‘partially’. On only one criterion it
scores and ‘X’ for ‘no’, which is ‘a verifiable standards integration’. This was published in the Journal
‘Computer Standards & Interfaces’.
Toval et al. (2002) describe in their paper, in which they propose the SIREN method, also a case
study. In this study they describe a project, for which they were contracted by the local government,
and in which they applied a risk assessment in the Regional Information Systems and
Telecommunications Office (RISTO). This however, was more based on the use of MAGERIT and led
the group to the definition of the SIREN approach. After that, they tested the new approach in a
project for the Regional Ministry of Labor and Welfare. The use of SIREN was found useful in
9
developing a secure system from the beginning and in improving productivity, since the time to
complete the RE process decreased.
Toval, Olmos and Piattini (2002) also present another case study, which focuses on the use of SIREN
develop a Personal Data Protection (PDP) catalog. They found that the approach can substantially
improve the software development teams’ productivity and that it enhances the quality of the
security requirements specification. According to Mellado, Blanco, Sánchez and Fernández-Medina
(2010), the designers of the SIREN method have also applied the approach to modeling requirements
of teleoperated systems for ship hull maintenance.
10
5
References
Gutiérrez, C., Moros, B., Toval, A., Fernández-Medina, E., & Piattini, M. (2005). Security Requirements
for Web Services based on SIREN. Symposium on Requirements Engineering for Information Security.
Paris, France.
Kotonya, G., & Sommerville, I. (1998). Requirements Engineering. Processes and Techniques. New
York: John Wiley & Sons.
Mellado, D., Blanco, C., Sánchez, L.E., & Fernández-Medina, E. (2010). A systematic review of security
requirements engineering. Computer Standards & Interfaces, 32(4), 153-165.
Mellado, D., Fernández-Medina, E., & Piattini, M. (2006). A common criteria based security
requirements engineering process for the development of secure information systems. Computer
Standards & Interfaces, 29(2), 244-253.
PricewaterhouseCoopers (2010). Information Security Breaches Survey 2010. London: Infosecurity
Europe.
Robertson, S., & Robertson, J. (1999). Mastering the requirement process. Reading: Addison-Wesley.
Sommerville, I., & Sawyer, P. (1997). Requirements Engineering: A good practice guide. New York:
John Wiley & Sons.
The Institute of Electrical and Electronics Engineers (1998). IEEE Guide for Developing System
Requirements Specifications. New York: The Institute of Electrical and Electronics Engineers.
Toval, A., Nicolás, J., Moros, B., & García F. (2002). Requirements Reuse for Improving Information
Systems Security: A Practitioner’s Approach. Requirements Engineering, 6(4), 205-219.
Toval, A., Olmos, A., & Piattini, M. (2002). Legal requirements reuse: a critical success factor for
requirements quality and personal data protection. Proceedings. IEEE Joint International Conference
on Requirements Engineering, Essen, Germany, 95-103.
Weerd, I. van de, & Brinkkemper, S. (2008). Meta-modeling for situational analysis and design
methods. In M.R. Syed and S.N. Syed (Eds.), Handbook of Research on Modern Systems Analysis and
Design Technologies and Applications (pp. 38-58). Hershey: Idea Group Publishing.
11
6
Appendix
Requirements
Explanation
SyRS/SyTS/SRS/STS/IRS <<number>>
<<textual explanation>>
Legend
SyRS System Requirements Specification
SyTS System Testing Specification
SRS
Software Requirements Specification
STS
Software Testing Specification
IRS
Interface Requirements Specification
12