eindhoven university of technology master … · system, product or service. ... validate and...
TRANSCRIPT
Eindhoven University of Technology
MASTER
Requirements engineering in a global enterprise
how can we reuse our knowledge?
Waterman, B.B.
Award date:2007
DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.
General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.
• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain
Take down policyIf you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediatelyand investigate your claim.
Download date: 02. Jun. 2018
FARW2007 4579BDK eering in a Global Enterprise
Can we reuse our knowledge?
01% ArXff
A lz;f OidiAB
P Penno Waterman - June 2007
Appendices
Contents
Appendix I. Glossary .. . .. . .. . . . .. . .. . .. . . . .. . . . . .. . .. . . . . . . .. .. . . . . .. . . . .. . . . . .. . . . .. . .. . .. . .. . . . . . . . . . .. .. . .. . . . .. . .. . .. . . . .. . .. . .73
Appendix II . Interviews Initial Problem Statement . .. . .. . .. . . . .. . .. . .. . . . .. . . . .. . .. . . . . . . .. . .. . .. . . . . . . . . . . . . .. .76
Appendix III. Exploratory Problem Analysis by literature . .. . .. .. . . . . .. . . . .. . . . . .. . . . .. . .. .. . . .. . . . .. . .. . .. .78
Appendix IV. Interviews Problem Analysis .. . .. .. . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . .. . . . . . . .. . .. . . . .. . . . . .. . .. . . . .. .. . . .. .83
Appendix V. Case Study Requirements Engineering . . . . . .. . .. .. . .. . .. . . . .. . .. . . . . .. . . . . . .. . .. . .. . .. . . . .. . .. . . . .85
Appendix VI. Requirements Engineering Terminology across the BUs of ABN AMRO ..104
Appendix VII. Explanation Root Cause Diagram . . .. . .. . .. .. . .. . . . .. . .. . .. . . . . . . .. . .. . . . . . . . . .. . .. . . . . .. . .. .. . .. . .109
Appendix VIII . Prioritized Requirements List . . . . .. . .. . .. . . . .. . .. . .. .. . . . . . . . . . .. . .. . .. . . . .. .. . .. . . . . .. . .. . .. .. . .111
Appendix IX. Setting NFRs at ABN AMRO. . .. . .. . . . .. . .. . .. . . . .. . .. .. . .. . . . . . . . . . .. . .. . .. . . . .. .. . .. . . . . .. . .. . .. .. . .112
Appendix X. Methods used for deriving a conceptual model from literature . .. .. . .. . . . . .. .. . .120
Appendix XI. Caliber RM . .. . .. .. . .. . . . . . . .. . .. . . . . . . .. . .. . . . . . . .. . .. . .. . . . .. . .. .. . .. . .. . . . .. . .. . . . . .. . . . . . .. . .. . .. . .. . . . .. . .. . .126
Appendix XII. Logical Data Model . . . . . .. . . . .. . .. . . . . . . .. . .. . .. . .. .. . .. .. . .. . .. . .. . . . .. . .. . .. .. . .. . . . .. . .. . .. . . . .. . .. . . . . .. .128
70
List of Figures
Figure 111 . 1 Waterfall Model for the Software Project Lifecycle (Sommerville, 1992) . . . . . . . . . . . . . . . . 79Figure 111 .2 Hierarchical decomposition of the requirements engineering domain (Wiegers, 1999)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Figure 111 .3 : A spiral model of the Requirements Specification process (Kotonya et al ., 1998) . . 81Figure III .4: Major Requirements Management Activities (Wiegers, 1999) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figure V.l Software Project Lifecycle BUNL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Figure V.2 Requirements Engineering Process BUNL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Figure V.3 Organization Chart Business Unit Netherlands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Figure V.4 Software Development Methodology BUNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Figure V .5 : Methodology (PDLC) Projects BUAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Figure V .6 : Requirements Engineering Phase BUAM (Part A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Figure V.7: Requirements Engineering Phase BUAM (Part B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Figure IX.2 Classification of NFRs (Kotonya, 1998) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Figure IX.3 Iterative Requirements Engineering process (ABN AMRO Group, 2006) . . . . . . . . . . . . . 116Figure IX .4 Stakeholders in setting NFRs at BUNL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Figure X.1 Generic Knowledge Management Model (De Jarnett, 1996) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Figure X.2 Knowledge Management Model (Demerest, 1997) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Figure X.3 The Quality Function Deployment Model (Akao, 1987) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Figure X.4 CMM model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Figure XI . 1 Interface Caliber RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Figure XII.1 UML Model for the reusable repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
71
List of Tables
Table IX. 1 Different types of NFRs at ABN AMRO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Table IX.2 Classification for business NFRs at BUNL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
72
Appendix I. Glossary
Business RequirementsSee high-level Business Requirement
ConstraintsRestrictions that are placed on the choices available to the developer for design and constructionof the software product .
Detailed RequirementDetailed Requirements categorizes the requirements necessary to actually build and deliver thesolution. They capture data, report, file and database schemas, valid data, values and ranges,algorithms, calculations, etc .
FeatureA feature is a set of logically related functional requirements that provides a capability to the userand enables the satisfaction of a business requirement .
Functional RequirementsRequirements that define the software functionality the developers must build into the product toenable users to accomplish their tasks, thereby satisfying the high-level business requirements .
High-level Business RequirementsRequirements that represent high-level objectives of the organization or customer requesting thesystem, product or service .
Interface RequirementInterface requirements specify the hardware or software elements with which the system, orsystem component, must interact or communicate .
Non-functional RequirementsRequirements that include standards, regulations, and contracts to which the product mustconform. These can be descriptions of external interfaces, performance requirements, design andimplementation constraints and quality attributes
Offshore OutsourcingTransfer of the responsibility for delivering IT Services to a provider who delivers these servicesfrom a continent different from where the recipient operates .
REM ForumThe REM Forum is a cross business unit co-operative body that looks at opportunities to addvalue in the area of Requirements Engineering . This is done by exchanging experiences andsolutions across BUs, by jointly working on common and global deliverables, and by supportingeach other in implementing successful solutions and best practices .
73
RequirementsDefinition of IEEE Std 610.12 :
1 . A condition or capability needed by a user to solve a problem or achieve an objective .
2. A condition or capability that must be met or possessed by a system or system componentto satisfy a contract, standard, specification, or other formally imposed document .
3 . A documented representation of a condition or capability as in (1) or (2) .
Requirements AnalysisRequirements Analysis follows the Requirements Elicitation stages as the second stage in theprocess . The Requirements Analysis stage includes such activities as identifying and analyzingrisks, constraints, assumptions and exclusions, as well as analyzing the priority of therequirements and their urgency (trade-off analysis) .
Requirements DevelopmentSee Requirements Specification
Requirements ElicitationRequirements elicitation encompasses all the activities to assemble the stakeholders and discover,reveal, gather, articulate, and define the requirements. This is usually the first step duringRequirements Specification.
Requirements EngineeringThe entire domain of Requirements Specification and Requirements Management
Requirements Engineering and Management ProcessThe term that is used in BUNL for all the processes in which Requirements Engineering is takenplace .
Requirements ManagementThe process of managing changes to the system requirements
Requirements RepresentationRequirements Representation follows the Requirements Analysis stage as the third stage duringRequirements Specification . Requirements Representation is the means (via documents, processmodels, diagrams etc.) by which the requirements are documented, presented and communicatedto all stakeholders in a reviewable format.
Requirements SpecificationA structured set of activities, which are followed to derive, validate and maintain a SoftwareRequirements Specification (SRS). Requirements Specification activities include requirementselicitation, requirements analysis and negotiation, requirements representation and requirementsvalidation.
Requirements Specification DocumentSee Software Requirements Specification
Requirements Specification processThree-stage iterative process . Each stage comprises the four aforementioned RequirementsSpecification stages (i .e . elicitation, analysis and negotiation, representation and validation) :
74
1. Identification of the High-level Business Requirements2. Identification of the User, Interface, Functional and Non-Functional Requirements
(decomposition of the High-level Business Requirements)3 . Define the Detailed Requirements (decomposing and dealing the User, Interface,
Functional and Non-Functional Requirements) .
Requirements ValidationRequirements Validation follows the Requirements Representation stage as the fourth stageduring Requirements Specification . Requirements Validation includes activities to review andverify the requirements, i .e. for completeness, accuracy, consistency, traceability and testability .All relevant project stakeholders are included in conducting the reviews .
Software EngineeringSoftware engineering is the application of a systematic, disciplined, quantifiable approach to thedevelopment, operation, and maintenance of software .
Software Development LifecycleA software development process is a structure imposed on the development of a software product .Synonyms include software lifecycle and software process . There are several models for suchprocesses, each describing approaches to a variety of tasks or activities that take place during theprocess .
Software Requirements Specification (SRS)Document that captures the validated requirements .
System RequirementsRequirements, which apply to the system as a whole and not just to the software components ofthe system.
Use CasesDocuments that capture the User Requirements
User RequirementsRequirements that describe the tasks the user must be able to accomplish with the product, serviceor system. These requirements are usually captured in use cases, scenarios or business processes .
Work OrderOrder that is sent to the assigned vendor in order to develop the requested system . Normally awork order comprises a Software Requirements Specification, a Logical Data Model, otherworking document and a financial analysis .
75
Appendix II. Interviews Initial Problem Statement
Interview list Initial Problem Statement
Interviews ABN AMROJos PloumSimanta DasDenis HagemanMark HendrickxArthur HahnKuldip MohantyThomas ten KortenaarBen BakkerKevin FitzgeraldStefan SimenonGeert EnsingRamnath SarmaWouter Schmitz
Interviews outside ABN AMRO
FunctionHead Global IT Policies and StandardsGroup Services Strategic Development and IntegrationChief Architect Group FunctionsChief Architect Private ClientsChief Architect Asset ManagementHead ADM Services Strategic Portfolio ManagementHead Global IT Strategy & ArchitectureGlobal Value Initiatives ManagementHead Global Vendor Relationship ManagementService Delivery Lead Netherlands/ EuropeGlobal Head Innovation and Development ServicesChief Architect Transaction BankingChief Architect BU Netherlands
FunctionClive Harris Value Creation Center IBM
Seminars Date Place"Haalt IT Outsourcing 2010?" September 26 2005 UtrechtStrategie Platform: Banken en Verzekeringen November 1 2005 Eefde, ZutphenBusiness en IT Alignment November 14 2005 Amsterdam
76
Interview Scheme Initial Problem Statement
Orientating Interviews
l . Introductioni. Background apprentice
2. Purpose of the interviewi. Background master thesis
ii . Clarification about interview structure, time and next steps
3. Role of the interviewed personi. What is your current position inside ABN AMRO Global IT services?
4. Can you elaborate in a global way on the Software Development Process at ABNAMRO in the following areas?
i. process (Global, BU)ii. key activities
iii . responsibilities
5 . In what respect have the traditional Business-IT relationship been changed after theHarvest and Symphony initiative?
i. What are the improvements of Harvest & Symphony?ii. What are the worsenings after Harvest & Symphony?
iii. How do you think the mutual cohesion between Business and IT can beimproved?
iv. What are the opportunities to improve this relation?
6. What are the risks towards the :i . old situation
ii. new situation (multi vendor approach)
7. Which data is necessary to give a better insight into this problem?
77
Appendix III. Exploratory Problem Analysis by literature
This appendix aims to provide an elaboration on the questions that have been stated section 2 .4 inthe report. This appendix will define what software requirements are (section 3 .1) and whensoftware requirements are set during the software development lifecycle (section 3 .2). ThereafterRequirements Engineering will be discussed (section 3 .3), followed by its two research fields :Requirements Specification (section 3 .4) and Requirements Management (section 3 .5) .
Section 3.01 What are Software Requirements?Due to the multiple levels of software requirements, many interpretations are legitimated todescribe what software requirements are . . These definitions represent different perspectives andvarying degrees of detail and precision (Wiegers, 1999) . For this reason the IEEE StandardGlossary of Software Engineering Technology (1997) defines a software requirement as :
1 . A condition or capability needed by a user to solve a problem or achieve an objective .
2. A condition or capability that must be met or possessed by a system or system componentto satisfy a contract, standard, specification, or other formally imposed document .
3 . A documented representation of a condition or capability as in 1 or 2 .
Software Requirements include five distinct types - high-level business requirements, userrequirements, interface requirements, functional requirements and non-functional requirements(Wiegers, 1999) . This paper will support this method of classifying Software Requirements,which will be discussed in the outline of this section .
High-level Business Requirements represent high-level objectives of the organization orcustomers requesting the system or product. They are captured in a document describing theproject's vision and scope .
User Requirements describe tasks the user must be able to accomplish with the product . These arecaptured in use cases or scenario descriptions .
Interface Requirements specify the hardware or software elements with which the system, orsystem component, must interact or communicate .
Functional Requirements (FRs) define the software functionality the developers must build intothe product to enable users to accomplish their tasks, thereby satisfying the businessrequirements .A feature is a set of logically related FRs that provides a capability to the user and enables thesatisfaction of a business requirement .
In addition to the FRs, which describe the behaviors the application must exhibit and theoperations it performs, the SRS contains non-functional requirements (NFRs) .NFRs include standards, regulations, and contracts to which the product must conform . These canbe quality attributes, which reflect the quality of the system to be built. Further, NFRs can beconstraints, which are externally imposed, like compliancy constraints . Finally, a collection of
78
different kind of NFRs, like portability, user friendliness and maintainability features, can beconsidered as NFRs.
Finally, all the different requirements types are documented in a software requirementsspecification (SRS), which describes as fully as possible the expected external behavior of thesoftware system. The SRS is used in development, testing, quality assurance, projectmanagement, and related project functions .
Section 3.02 When are Software Requirements set?Most projects go through similar stages on the path from origin to completion . Meredith et al .(2000) defined a project lifecycle as the stages that have to be challenged to reach completion .Traditional software engineering emerged around 30 years ago as software projects becameincreasingly ambitious to missed deadlines, cost overruns that result in difficulties in softwareproject management . For this reason, one of the major accomplishments in the field of softwareengineering was the recognition of the software lifecycle (Arndt, 1999) .A practical application of a Software Development Lifecycle is the waterfall model, which isdepicted in Figure HI . 1 . This model views the production of software as being divided into anumber of distinct phases : problem definition, requirements analysis, design, testing,implementation and maintenance . During requirements analysis, the requirements are specified .
P.bb .,a.finWm
OIY1~,~6
-4
$j'SICID ~Son-re tlexip
Ia~picmculcucnaM uW onJOg q
1negrabnandtom L9Wni h
Op.ndanoed∎mI~Ala~das
Figure 111 .1 Waterfall Model for the Software Project Lifecycle (Sommerville, 1992)
Another example of a software development lifecycle model is the V-model . This model showstest activities beginning in parallel with the corresponding development activities . For furtherreading this paper will refer to the work of Davis (1993) .
Section 3.03 Requirements EngineeringRequirements Engineering is a relatively new term, which has been invented to cover all of theactivities, involved in discovering, documenting and maintaining a set of requirements for acomputer based system (Kotonya et . al, 1998) .Problems, related with Requirements Engineering are one of the main reasons for softwareprojects failures (Lopes et al ., 2004) . This means that the final product does not meet all therequirements imposed by the users . According to Oberg et al. (2000) the following issuesregarding Requirements Engineering could be identified :
79
• Requirements are not easy to describe in words ;• There are different types of requirements in different levels of details ;• It can be impossible to manage the requirements if they cannot be controlled ;• Most requirements change during the project life cycle .
Lopes et al. (2005) estimate that 40 per cent of the requirements generate rework during theproject life cycle . The earlier a problem is detected and solved, especially during the requirementsphase, the earlier other problems are minimized in the following project phases .
This research concerns Requirements Engineering for software systems . According to Wiegers(1999), Requirements Engineering can be subdivided into Requirements Specification andRequirements Management . Requirements Specification can be further subdivided into fouriterative phases : elicitation, analysis, specification and verification (Thayer et al ., 1997 ; Kotonya,1998). This decomposition is depicted in Figure 111 .2 .The next sub sections will discuss the concepts of Requirements Specification and RequirementsManagement .
Requirements Specification -~ Requirements Management
Figure 111.2 Hierarchical decomposition of the requirements engineering domain (Wiegers, 1999)
Section 3.04 Requirements Specification ProcessThe Requirements Specification Process can be defined as a structured set of activities, which arefollowed to derive, validate and maintain a Software Requirements Specification (Sommerville etal., 1997) .A complete process description should include what kind of activities are carried out, thestructure or schedule of these activities, the person who is responsible for each activity, the inputsand outputs to or from the activity and the tools used to support Requirements Engineering . Ingeneral, the Requirements Specification primarily deals with the content of requirements . Asdepicted in Figure 111 .2, Requirements Specification include four phases : elicitation, analysis andnegotiation, representation and validation (Kotonya et al ., 1998 ; Thayer et al, 1997) .
Requirements ElicitationDuring requirements elicitation, requirements are gathered from different sources at differenttimes during the project . The elicited requirements have different audiences and purposes, andneed to be documented in different ways. In fact, the high-level business requirements must not
80
exclude any user, interface, functional and non-functional requirement and all requirementsshould be traceable to their source from which they were gathered. In this phase it is also neededto elicit NFRs from the most appropriate sources (Wiegers, 1999) .
Requirements Analysis & NegotiationRequirements Analysis involves refining, and analyzing the gathered requirements to make sureall stakeholders understand each other, and to find errors, omissions and other deficiencies(Wiegers, 1999) . The Requirements Analysis stage includes activities as identifying andanalyzing risks, constraints, assumptions and exclusions, as well as, analyzing the priority of therequirements and their urgency .
Requirements RepresentationThe representation of requirements is the means (via documents, process models, diagrams etc .)by which the requirements are documented, presented and communicated to all stakeholders insome consistent, accessible and reviewable way . The way of representing requirements dependson the nature of the requirements (Wiegers, 1999) .
Requirements ValidationRequirements Validation activities ensure that requirement statements are accurate, complete anddemonstrate desired quality characteristics . Requirements, which seem fine by reading them inthe SRS, might cause problems when it is tried to actually work with these requirements .Ambiguities and vagueness can be discovered by the writing of test cases from the requirements .These requirements have to be adjusted if the requirements are to serve as a reliable foundationfor design and final system verification (Wiegers, 1999) .
The different phases in Requirements Specification are repeated until the SRS is accepted . Figure111.3 represents the Requirements Specification process in a spiral instead of a Waterfall modelsince the Requirements Specification process has the form of an iterative process .
informal smewwnft ofrequirnnents
Ucctton pllrtc Accept!!r)ctrinCr# co- reerifer spiral
Reywrreineut> docutncnt , I I i -I } I 1 - Agrocd
and validation report recluuemchrts
Draft roquimucntsdox.uunent
Figure 111.3: A spiral model of the Requirements Specification process (Kotonya et a1 .,1998)
81
Section 3.05 Requirements Management ActivitiesSoftware requirements are always changing, reflecting the changing needs of stakeholders, thechanges in the environment in which the system is to be installed, the changes in the businesswhich plans to install the system, the changes in laws and regulations, etc . These changes have tobe managed to ensure that they make economic sense and contribute to the high-level businessneeds (Kotonya et a1 .,1998) .Requirements Management can be defined as the Requirements Engineering activity that aims atcontrolling changes made to requirements . The principal requirements management activities arechanging control and changing impact assessment (Kotonya., 1998 ; Lormans et al ., 2004) .
This appendix will not adopt the definitions of Leffingwell et al . (2000) who include elicitation,organization, and documentation of requirements under management activities . In the setting ofthe paper, requirements management is primarily a supportive process, which helps to manageevolving requirements throughout the system's lifecycle. This paper favors the interpretation ofWiegers (1999) that Requirements Management can be subdivided in four different disciplines, asdepicted in Figure 111 .4.
• Controlling the changes to the requirements baseline
• Controlling versions of both individual requirements and requirements documents
• Managing the relationships between requirements, and links or other dependencies
between individual requirements and other project deliverables
• Tracking the status of the requirements in the baseline .
RequirementsManagement
GCheap Control
• Proposing changes• Analyzing impact• Making decisions• Communicating• Incorporating• Measuring
rec~utrementastabillty
Vmlon Control
• identif},ingrequirementsdocumentversions
• Identifyingindividualrequirementrevisions
RequirementsTracing
• Defining linksto otherrequirements
• Defining linksto other systemelements
RequirementsStatu Tracking
• Definingrequirementstatuses
• Trackingrequirementsthat have eachstatus
Figure 111.4 : Major Requirements Management Activities (Wiegers, 1999)
82
Appendix IV. Interviews Problem Analysis
Interview List Problem Analysis
Interviews ABN AMROPeter PendersBert DubbelmanReginald BloemenLeon van LithRon CordemeijerTon GroenDebra MeoTerri SprattDawn LawlerJohan CaalsPatrick TerpstraRonald StronksAdrie VerdaasdonkChris de JongTon Van Velzen
FunctionTransition and Transformation ADM ServicesProcess and Quality Expert IT BUNLProcess and Quality Expert IT BUNLRequirements Manager BUNLProcess Improvement ManagerOperational Control BUNLRequirements Engineer BUNARequirements Engineer BUNAProject Management Office BUNATransition & Transformation BUAMBusiness Analyst BUAMProject Manager BUAMBusiness Analyst BUPCTransition & Transformation BUPCRequirements Engineer BUTB
Interviews outside ABN AMROPathikrit BandyopadhyayAvinash SinghAmit KatdareDennis GadaBas de NatrisPrasad Manohar
FunctionQuality Testing Tata Consultancy ServicesApplication Management Vendor team TCSApplication Management Vendor team TCSEngagement Manager Infosys TechnologiesGlobal Base Growth Executive IBMQuality Testing Infosys
83
Interview Scheme Problem Analysis
• Introduction :o Introduction research studyo background of the interviewee .
• Refinement of the problem : are the preemptive assumptions right in respect to theRequirement Engineering?
o Process modelo Operating model (Project leader--> Business Analyst 4 SME Requirement
Engineer 4 Vendor)
• Process analysis :o What are the most common IT projects for this Business Unit?o What are the most often occurring failures (costs and time) regarding
Requirements Engineering?∎ What are the success factors for proper Requirements Engineering in
your BU?• What are the downfalls for proper Requirements Engineering in your
BU?
• Requirements Specification :o How does Requirements Specification take place at this moment?o What are the success factors?o What are the downfalls?
• Requirements Management:o Is it possible to manage requirements globally in respect of reusing requirementso What are the success factors?o What are the downfalls?o Is there already a tool or experience in a managing model for improving
Requirements Engineering?
• MeasurementWhat is the status of the use of metrics for Requirements Engineering?
o Tooling: Are there tools used for supporting the setting of requirements (likeCaliber RM)?
o Is there a tool which is able to generate a visibility on efficiency towards• Costs (too high)∎ Throughput time (too long)∎ Knowledge and skills
o Visibility on effectiveness (customer satisfaction)
84
Appendix V. Case Study Requirements EngineeringThis appendix will discuss the exploratory case studies executed at four BUs of ABN AMRO :BUNL, BUNA, BUAM and BUTB .
1 . Requirement Engineering at Business Unit Netherlands (BUNL)What type/nature of Business Unit is the focus of the case study about?Business Unit Netherlands (BUNL) is one of the biggest Business Units of the ABN AMROGroup. BUNL consists of six subunits: Value Center Particulieren, Value Center Zaken, Finance,Risk Management and Services Nederland . The organizational structure for BUNL is depicted inFigure V.3. Services IT Netherlands is a sub department of Services Nederland, covering theoverall IT for BUNL .
What is the history of BUNL with respect to IT?Before the Harvest & Symphony initiative, IT projects were executed by business and ITexecutives. This way of working in projects imposed an officious working combination betweenthe demands of the business and the capabilities of the IT personnel . When the Harvest andSymphony has started in November 2005, BUNL had to change their traditional way of workingfor conducting IT projects, since the ABN AMRO personnel had to provide proper andunambiguous instructions to IT vendors that are responsible for building the application . In lineof these changes much of the traditional IT developers that were working for ABN AMRO flewoff to IBM. As a result, a communication vacuum arose how to realize the demands of thebusiness in application to be built . For this reason, it has become increasingly important toprovide a proper requirements document to ABN AMRO its AM vendor, TCS .
How are requirements set in the software development lifecycle at BUNL?BUNL is using the Dynamic System Development Method (DSDM) as a lifecycle methodology .DSDM is based on an iterative approach, which impose that changes are easily made . At BUNL,DSDM describes the process of executing Application Development and Enhancement Projectsby the Project Managers . This consists of a set of phases to be executed from project initiation toproject closure: Pre project, Feasibility Study, Business Study, Functional Model Iteration,Design & Build Iteration, Implementation and Post-project, depicted in Figure V .1 .
~ omdL~ prodma o~d
~ Oasod~~ NafFe~wd
~ 1~ust coeoM ~
; ® NOArm awoa dd nn d*W+ &VA" sq*WROM
Figure V.1 Software Project Lifecycle BUNIL
85
Who are the key actors/partners in the REM process?The REM process is a labor intensive process spread over a broad range of stakeholders that giveinput to this process. This section will provide a short overview of the main stakeholders insetting requirements :
• Requirement Manager (role of Functional Manager) : This person is involved in theexploitation phase before the Feasibility Study is started . He is the author of theRequirement List. At the end of the project, the Requirement Manager will update theRequirement List and the total set of Requirements based on the realization of the PRL .The role of Requirement Manager is likely to be more an administrator role rather than anactive operational role in the project .
• SME Requirement Engineer: This person is the requirements author on IT side .• Requirements Engineer (role of Business Analyst) : This person is the requirements
author of the business side .• Center of Expertise : These persons are SME's in setting up requirements .• Process Improvement Team. In this team process improvement and new REM
developments are executed .• Harvest AM vendor: The AM vendor TCS will design and build the system from the
requirements that are listed in the PRL, together with the Business Process Model, theUse Cases, Logical Data Model and the Functional Model . This information will berepresented in the work order.
Test vendor: Infosys forms the role of Test Vendor for BUNL . The Business AcceptanceManager executes test cases to show if the high level business requirements reflect the detailedrequirements .
Requirements Engineering process at BUNLThe total process for setting requirements and managing them for BUNL is called RequirementsEngineering & Management (REM) . The total REM process is depicted in Figure V .1 .The REM process starts with a requirement list during exploitation of the project, which iscontinuously updated. The input for the Requirements list is the Business Process Model,describing the process flow, the collected use cases and the logical data model . Together with thenew wishes and the existing system documentation, the REM process is started by exploitation .The Requirement Engineer and the Business Analyst are executing these activities .However, the actual setting of requirements is started in the Feasibility Study and the BusinessStudy. The objective of the Feasibility Study is to start delivering a set of high-level businessrequirements. After the Feasibility Study the Business Study is started . In this phase theRequirement Engineer in the role of business analyst starts actually setting requirements . TheBusiness Study extracts requirements from the business process model and the use cases . Theresult is a Prioritised Requirement List (PRL) containing a set of high-level businessrequirements . Further, in the Business Study the high-level business requirements are beingelaborated in the functional, non functional, interface and user requirements . The requirements inthe PRL are further updated.In the Functional Model Iteration (FMI) the requirements in the Business Study are furtherelaborated in Detailed Requirements and the Functional Model is developed . Generally, thisphase takes the longest time . When all the different types of requirements are detailed enough forproper and unambiguous understanding, a work order is sent to the vendor. This process isexecuted by the Subject Matter Expert (SME) Requirement Engineer . This work order containsall relevant information for building the system, including the detailed Requirements . At the end,
86
the PRL is going back to the Requirements Manager and can be updated with changes that arediscovered during the REM process .
Figure V.2 Requirements Engineering Process BUNL
Baselining RequirementsA closer look at Figure V .1 shows that the PRL is baselined. Baselining can be considered as anapproval of the constructed PRL by the different stakeholders in the organization. The PRL isfirst baselined when the high-level business requirements are set . This forms the starting point fora further detailing by decomposing the high-level business requirements in user, functional, non-functional and interface requirements . As a consequence, the requirements are further detailedinto Detailed Requirements and are baselined for the second time . Finally, the baselined PRL issent to the vendor and is built . After fitting in the changes, the PRL is baselined for the third time .
87
Figure V.1 reveals that the setting of requirements is not only limited to one phase in the softwaredevelopment lifecycle, rather than spread over several phases . In order to provide anunambiguous understanding when requirements are set in the lifecycle, this appendix proposes totalk about three different phases regarding the setting of requirements :
∎ Iterative process 1 : setting high-level business requirements∎ Iterative process 2 : setting user, interface, functional and non-functional requirements∎ Iterative process 3 : setting detailed requirements
Setting prioritized requirementsFigure V.2 shows that requirements are set in an iterative way. In fact, the process for specifyingrequirements consists of four stages : elicitation, analysis, representation and validation, which areexplained extensively in Chapter 2. The specification of requirements is a rather difficult processin which a trade-off analysis has to take place to prioritize requirements . However, it is importantthat essential work is done and that only less critical work is omitted . Since time boxes are fixed,the deliverables from a time box could be less than originally was envisaged .
The MoSCoW rules are used to achieve clear prioritization of requirements. For every IT projectthe following requirements have to be defined :
• Must have requirements . These are requirements that re fundamental for the system .Without them the system would be unworkable and useless . The Must Haves define theminimum usable subset.
• Should have requirements . These requirements are set for important requirements forwhich there is work-around in the short-term and which would normally be classed asmandatory in less-time constrained development, but the system would be useful andusable without them.
• Could have requirements . These requirements could be more easily left out of theincrement under development .
• Want have requirements . These valuable requirements can wait until later developmenttakes place .
How is Requirement Management conducted at BUNL?Requirements Management contains the process through which new or changed requirements ofall types are high-level defined, based upon new wishes or problems that have been raised duringmaintenance of the system and based upon the operational plan. The way these requirements aredefined is a kind of "light" version of the Requirements Engineering process as is described forprojects, so it will follow the four stages (elicitation - analysis - representation - validation) .These new or changed requirements become available by means of Requirements List, and willbe input for starting development and maintenance projects . During the project a RequirementsManager could be consulted, since this person is one of the stakeholders . At the end of a project,the Requirements Manager will update the Requirements List and the total set of requirementsbased on the realization of the PRL .
88
What are the biggest problems in the REM process?This section will provide an overview of the different problems in the REM process . Thisinformation is obtained by conducting semi-structured interviews with several experts in BUNL,represented in Appendix IV . In general, one of the biggest problems of the REM process is theimmaturity of BUNL with the changes that were imposed by the Harvest and Symphonyinitiative . Besides, the old problems had not been resolved yet, since the stakeholders originatingfrom the business and from the IT are still struggling with each other .In summary BUNL faces the following problems :
• The typology for setting requirements is changing . This is caused by four things :o Vendors are not familiar to cope with different requirement typeso Formulating requirementso Structure in setting up requirementso REM employees have to think in requirements rather than in solutions .
• Resource related problems, like :o Increase the analytic skills of the employeeso Increase the knowledge of the Dutch and English language for the employeeso A straight forward describing of the requirements is lacking.o Personnel didn't finish their training for requirements engineering.
• A proper way of using requirements traceability is still difficult to establish . By this wayalready identified requirements can be coupled to new systems to be developed, resultingin time and cost reductions .
• The REM process lack appropriate metrics to monitor the performance for setting properrequirements. In fact, ill-defined requirements have to be redefined during the REMprocess, which imposes increasing costs .
• Decrease the level of variations for setting requirements in PRL's . This will contribute toan easier understanding by the different stakeholders .
• Try to reuse as much as earlier defined requirements as possible, like functional, non-functional, user and interface requirements . At this moment, this is hardly realized .
• Vendors have to be involved in an earlier phase in the project . This will contribute to aneasier understanding by the different stakeholders that result in decreasing of the totalthroughput time of the system.
• The information in the business has to be shared in order to have viable knowledgetransfer throughout the regions . By this way, BUs are able to learn from each other anddon't have to "reinvent the wheel" .
• Establishment of a continuous dialogue besides the execution of projects . Thiscontributes to a proper mutual understanding that result in reductions in throughput time .
What are the tools that BUNL are using regarding the REM process?BUNL is using Caliber RM as a Requirement Management tool . This system has the ability tovisualize the requirements track, store already tracked requirements and couple this to new
89
systems to be build. At this moment, Caliber is even used for setting requirements in the PRL . Atthis moment BUNL is the only BU who is actually executing Requirement Management by theuse of a tool . A detailed description of the Caliber RM will be provided in Appendix XI .
Since the REM process is a part of the software development lifecycle, many tools regardingsoftware development are used in the REM process . In fact, project managers use MicrosoftProject for the total planning of the projects, including the setting of requirements . The ABNAMRO time recording system (ATR) is used to report the amount of effort ( i .e . hours) people arespending during a software development phase . Finally, CASCADE is used for the storage of allthe relevant project information in BUNL.
90
F4e
00vn
uvNU>
á
z
11
á
S
á
ly,.g
S
1,12j
g!g,
a
Q
9sin,
~11àl,
1 ~
r,
li
Wig
2. Requirement Engineering in Business Unit North America(BUNA)
What type/nature of Business Unit is the focus of the case study about?Business Unit North America (BUNA) is one of the biggest BUs of ABN AMRO in respect to thetotal revenue of the ABN AMRO Group . BUNA covers the activities from the LaSalle BankCorporation that has been merged into the ABN AMRO Group since 1979 . The LaSalle BankCorporation is the holding company for LaSalle Bank N .A., headquartered in Chicago Illinois,and LaSalle Bank Midwest, headquartered in Troy, Michigan. The LaSalle Bank Corporationcovers total assets of 986 billion Euros and operate more than 400 branches and 1,600 ATMsunder the LaSalle Bank brand. In Canada, the BU North America services clients across ourbusiness offering through offices in Toronto, Montreal, and Vancouver .The LaSalle Bank N.A. has three main subsidiaries : LaSalle Business Credit, LaSalle NationalLeasing Corporation and LaSalle Financial Services .
What is the history of BUNA in respect of IT?In September 2005 ABN AMRO started the outsourcing and offshoring program Harvest andSymphony, which has been described in Chapter 1 of the report . Due to this program, theoperating model had to be changed since the actual building of application had to be taken placeby the IT vendor . As a consequence, it became even more necessary to give proper requirementsto the assigned AM vendor of BUNA : Infosys .
How are requirements set in the software development lifecycle at BUNA?BUNA uses for developing their software applications another methodology than BUNL . BUNAuses the Methodology for ABN AMRO Projects (MAP) for the process of executing ApplicationDevelopment and Enhancement Projects . Figure V.4 shows in an abstract way the softwaredevelopment process. All the critical activities for developing an application are represented here .Although this process is in many aspects similar to the Software Development Process in BUNL,there are some slight variations . For example, at BUNL the actual building and development of anapplication is taking place offshore (i.e. in India), while the development of applications fromBUNA are taking place onshore (i .e. in the USA) in special auxiliary branches .
Figure V.4 Software Development Methodology BUNA
` Project Ovér~i_ht al!d.
As,5csq Clangei , Regvcj slaws- l..ongoi fihj4facïagë gco}~ Pra~ t
SYSTEM DEVELOPMENT LIFECYCLE ACTIVITIES'
Development & Imnlementation
Develop/ I Test I Train/ ' ImplementBuild convert
92
How is the Requirement Engineering process executed inside BUNA?In respect of Requirement Engineering and Management BUNA uses the Requirement, Analysisand High-Level Design (RAD) procedure to define requirements . At BUNA there are less than 20business analysts and the amount of projects parallel is about 40 . One can easily see that this is arelatively small amount in comparison with the size in revenue of BUNA. The underlying reasonis that BUNA is at this moment in a cost cutting phase, which has resulted in very few ITconsultants and a number of projects that are down due to a lack of available resources
The same as for BUNL, Requirement Engineering at BUNA is an iterative, cross-functional, andcollaborative process. The purpose of this process is to ensure that the appropriate resourcesfollow a consistent methodology for creating validated and approved Use Cases, BusinessRequirements, Functional Requirements and Non-Functional Requirements. However, the mainRequirements Engineering activities at BUNA covers three aspects :
• Eliciting Requirements . This is the process in which the Requirements Analyst workswith the stakeholders to identify the requirements .
• Requirements Documenting . Capturing the requirements in a document• Requirement baselining. In this stage the requirements are signed off and are ready to be
transferred to the IT developer .
The Requirement Process is started with the Requirement Management Plan (RMP) . This is acontract between the Requirement Analyst and the Project Lead . In the RMP is described how theelicitation process and the documentation process will occur .After this plan has created, the Business Requirements are set up . These Business Requirementsare captured in the "Business Requirements & Software Requirements Specification " . Thisdocument has a project-level focus and captures besides the Business Requirements also theFunctional and the Non-Functional Requirements . This document aims that each BusinessRequirement can be traced to a Detailed Requirement . This document is constructed by theBusiness Analyst.Further, the User Requirements are captured in Use Case Documents . The Interface Requirementsare handled differently than they are handled in BUNL. The Interface requirements areconsidered in BUNA as Non-functional Requirements, while in BUNL the InterfaceRequirements are captured in the System Architecture Document (SAD) .
As a result, BUNA captures requirements at tow different levels :
• Business Requirements . These are the high-level requirements that set the scope of thesystem to be built.
• Detailed Requirements . These requirements reflect the Functional, Non-Functional, Userand Interface requirements that result from decomposing the Business Requirements.
Setting the prioritized requirementsDuring the Requirements Engineering process, stakeholders negotiate which requirements have tobe in the "Business Requirements & Software Requirements Specification " and which not. On thebasis of prioritization classes an analysis can take place. BUNA distinguished four different typesof priorities :
• Critical. The project will fail if this requirements cannot be met .
93
• High. The requirement contributes significant value to the overall success of the project,by reducing labor costs, risks or turn time . However, there are manual workarounds orother alternatives that could be deployed if necessary for a short time .
• Medium. The requirement provides value but is not essential . There may be manualworkarounds that can effectively be used to provide the same functionality withoutsignificant downside .
• Low. These requirements are nice to have .
Within each category that has been listed above, all the requirements must be weighted accordingto importance within that category. For example, if there are 5"CriticaP' requirements, each onemust have a different rating . The most important of the 5 "Critical" requirements will have apriority of "C-1"and the least important of the 5 "Critical" requirements will have a priority of"C-5". By this way, no two requirements may have the same priority .
How is Requirement Management conducted now?BUNA defines Requirements Management as all the requirement-related activities within aproject, from elicitation and documentation of the requirements to the formal change controlprocess, after the requirements have been baselined. In order to conduct the changes inrequirements after the project has been baselined, BUNA is using Test Director to capturechanges. According to Requirement Engineers at BUNA, they are able to achieve a goodtraceability of requirements by this tool .However, BUNA looks at this moment for a similar kind of Requirements Management tool, thatBUNL and BULA are using (i .e. Caliber RM) .
Who are the key actors/partners?This part contains a subset of stakeholders who are involved in the Requirements Engineeringprocess at BUNA .
• IT Project Manager . This person is responsible for resolving issues and conflicts that mayarise in the process with regard to budget, schedule, resource constraints andprioritization .
• Business Requirements Analyst. This person is responsible for the setting up the businessrequirements. Further this person
• IT Requirement Analyst. This person is responsible for leading and facilitating allactivities in the Requirements Engineering Process . His main task is to ensure that thedocumented requirements are consistent, unambiguous, traceable, necessary feasible andwritten in an appropriate level of detail .
• Technical Lead . This person ensures that requirements are technically feasible, written atan appropriate level of detail and provide an adequate basis for design .
• Testing Lead. This is the person that ensures that the requirements are unambiguoustraceable and testable .
• Client Stakeholder . This person educates the Requirement Analyst about the businessdomain as needed and will allocate resources to the project team with the appropriatesubject matter expertise to provide requirements .
• Harvest AM vendor: The AM vendor Infosys will design and build the system from therequirements that are listed in the "Business Requirements & Software Requirements
94
Specification", together with the Business Process Model, the Use Cases, Logical DataModel and the Functional Model . This information will be represented in the work order .
• Test vendor: TCS the role of Test Vendor for BUNA .
In some projects there is a mix between the role of the Business Requirements Analyst and the ITRequirement Analyst . It can also occur that a IT Requirement Analyst writes the requirement andthat a Requirement Analyst lead has a mentoring role for the Requirement Analyst .
What are the biggest problems in managing requirements?This section will provide an overview of the different problems in the REM process . Thisinformation is obtained by conducting semi-structured interviews with several experts in BUNA,represented in Appendix IV .One of the biggest problems is the relative immaturity of BUNA regarding the development andmaintenance of systems by external IT developers, as a result of the Harvest and Symphonyinitiative .In summary BUNA faces the following problems. These problems are specific for BUNA .Subsequently, these problems are cross-analyzed in order to identify problems that occur at all thefour selected BUs .
• It is difficult to "narrow down" the Business Requirements into Detailed (technical)Requirements . Often requirements are forgotten or these requirements are represented inan ambiguous way.
• In defining Business Requirements much time is spend on defining what has to be buildduring meeting with all the stakeholders involved .
• BUNA uses hardly requirements that are constructed earlier, but are often "reinventingthe weal". In this way, the throughput time for setting Detailed Requirements isunnecessary long and could possibly be decreased by reusing requirements . Especiallythe non-functional requirements in respect of Maintenance and Enhancement are at firstsight likely to reuse .
• The Business availability of Subject Matter Experts (SMEs) has to be increased . Delaysare often created due to the absence of crucial personnel .
• The business is changing their demands continuously, which result in many changerequests and long project times .
. Every project has its own Quickplace for storing their project related information . In thisway, there is no single repository for project information used . Also, there is no documentmanagement system with results in a marginal likelihood for reusing requirements .
. In the beginning of the Harvest & Symphony initiative, the Requirement skills of thevendors were lacking, since these resources were more Technical Leads than Harvest AMvendor. At this moment their qualification is increasing, although they are sometimesmissing some essential contextual and requirement knowledge .
95
• Not all projects are following the intended way of executing change requests . Thisunstandardized way of setting change requests, takes more time to process the changesthan the a standardized way does .
• Non Functional Requirements are difficult to manage. BUNA has set up 19 differenttypes of these requirements . The requirements types are not in all cases the same as inBUNL, since the setting of requirements types is subjected to interpretation . Functionalrequirements are visible requirements, although non-functional requirements concerncapacity and performance and are intangible . Now there are pages been set up in the"Business Requirements & Software Requirements Specification" how to manage non-functional requirements .
What are the success factors of BUNA?This part will discuss some identified success factors of BUNA in respect to RequirementsEngineering .
• BUNA is using a new template for defining functional and non-functional requirements,which has been referred to several times in this case study. This" Business Requirements& Software Requirements Specification has increased performance of defining BusinessRequirements and Detailed Requirements .
• The responses on peer reviews are executed well in order to get continuous improvement .In fact, prior to baselining and signing off, stakeholders verify that the requirements arecorrect and complete as part of group walkthrough reviews and individual reviews of therequirements. When stakeholders sign off on the requirements, they are verifying that therequirements encompass the full scope of features and functionality required in order toaccomplish the business objectives of the project .
• Test Director is performing well to provide a proper traceability of requirements .
What are the tools that BUNA is using?As discussed earlier in this case study, BUNA is not using a Requirements Management tool likeCaliber RM, just like BUNL and BULA are doing. In the short run, BUNA wants to start usingsuch a system.
Further, in BUNA project managers use Microsoft Project for capturing the project planning .Next, the Enterprise Portfolio Information Centre (EPIC) tool provides an integrated set ofprogram and project management tools . Finally, no document management system likeCASCADE is used at BUNA, since all the documents are stored at a Quickplace of that certainproject .
96
3 . Requirement Engineering in Business Unit Asset Management(BUAM)
This section of Appendix V contains the results of a case study executed at Business Unit AssetManagement . Due to its relatively small size, this section is relatively shorter than the previoustwo case study examples.
What type/nature of Business Unit is the focus of the case study about?The BU Asset Management (BUAM) provides mutual funds and handles investment mandatesfor institutions, private banking clients and retail clients . BUAM forms together with BU GlobalMarkets and BU Transaction Banking the global BUs of the AAB, with a local presence in 26countries across Europe, the Americas, Asia and Australia . Portfolio management activities areconcentrated in six key centers : Amsterdam, London, Chicago, Atlanta, Hong Kong andSingapore .BUAM manages EUR 208.7 billion (as at 31 March 2007) in specialist mandates and in over 500mutual funds . BUAM's products are distributed directly to institutional clients such as centralbanks, pension funds, insurance companies and leading charities . The funds for retail investorsare distributed through ABN AMRO's consumer and private banking arms, as well as third partydistributors. Its institutional client business represents just over half of the assets managed, thefund business comprises a third, while the remainder is in portfolios managed for Private Clients .
What is the history of BUAM in respect of IT?In respect to the development of software applications, BUAM is a relatively small business unit .Before the Harvest & Symphony initiative started, there was an officious relation between thedemands of the business and the capabilities of the IT personnel during the development andmaintenance of systems to be built. However, this resulted in a process in which visibility wasscarce due to the officious way of working .In September 2005 ABN AMRO started the outsourcing and offshoring program Harvest andSymphony. BUAM had to change their traditional way of working. Many of the traditional ITpersonnel flew off to IBM and Infosys became the AM vendor ofBIJAM.
Due to the small size of BIJAM in respect to IT, the communication between business,Requirements Engineers of BIJAM and the vendors is still very informal containing shortcommunication channels . By this informal way of working, it occurs often that the business aimsto have changes in late stadiums of the software development phase .
How is the Requirements Engineering process executed at BUAM?At BUAM, the Project Development Life Cycle (PDLC) describes the lifecycle process of theexecution of Application Development and Enhancement Projects . This software developmentmethodology consists of a set of concurrent phases to be executed from project initiation toproject closure . The main steps in this methodology are visualized in Figure V .5. The remainderof this part will discuss one phase in the PDLC : the Requirements Analysis, represented by a bluecircle in Figure V .5 .This stage sets the requirements of the project are set . The Requirements Analysis at BIJAMcomprises four iterative phases : elicitation, analysis, representation and validation. This forms thebasis of the entire functional scope of the project . The Requirements Analysis phase is depicted inFigure V.6 and V .7 .
97
Normally a project starts by the approval of a Project Initiation Document and followed by aProject Definition Document (PDD) that captures the high-level business requirements . Thedetailed requirements are captured in a Requirements Definition document (RDD) . The SMERequirements Engineer, who is also called the Business Analyst, creates this document . The RDDcovers both Functional Requirements as Non-Functional Requirements. These Non-FunctionalRequirements include security requirements such as access control and authentication . In additionto Functional Requirements, Non-Functional Requirements (Technical Requirements) likePerformance, Availability, etc . are determined and are agreed on with Infrastructure teams .Further, BUAM does not use formal prioritization rules for analyzing and negotiating the elicitedrequirements, but execute this task relative informal .
Who are the key actors/partners?This part will contain an overview of all the stakeholders involved during the RequiremnetsDefinition of BUAM .
• Relationship management . These stakeholders are responsible for the creation of theProject Initiation Document .
• Project Manager. This persons makes the Project Definition Document (PDD) . The PDDis a Word document that contains a high level requirements and the business scope .Furthermore this persons executes the Business Case .
• SME Requirements Engineer (Business Analyst). This person creates the RequirementDefinition Document (RDD). In the RDD the detailed requirements are captured. Thesedetailed requirements contain the Functional Requirements as well as the Non-FunctionalRequirements .
• Harvest AM vendor. The Harvest AM vendor (Infosys) is responsible for the actualbuilding of the application on the basis of the withdrawed RDD .
What are the biggest problems in managing requirements?This section will provide an overview of the different problems in the Requirements Definition .This information is obtained by conducting semi-structured interviews with Business Analystsand Transition and Transformation experts in BUAM, listed in Appendix IV .In summary BUAM faces the following problems . These problems are specific for BUAM .Subsequently, these problems are cross-analyzed in order to identify problems that occur at all thefour selected BUs .
• One of the biggest problems is the informal way of communication in BUAM, whichoften results in unexpected delays .
• Further, the business departments in BUAM has relatively much power in comparisonwith other BUs . Often it occurs that the business is asking for a change at the end of theRequirements Definition just after baselining the captured requirements . This lateinvolvement of business demands, leads to delays and cost increases . At this moment thebusiness representatives sign the phases that are already conducted, in order to avoiddiscussion afterwards .
• The project times are longer due to the introduction of new partners, like Infosys, and dueto codes like SOXA that should not be complied to some years before . These new aspectsin software development leads to significantly longer project times .
98
• At this moment, every element has to be invented from scratch. In other words, there arehardly any components that are reused during the software development process .
• At this moment, many stakeholders involved for capturing requirements in the RDD, arestill thinking in solutions rather in requirements . Problems with ambiguous requirementsresult in many overwork and increasing costs .
• Due to the introduction of Harvest & Symphony, the amount of extra layers in theorganization has increased to which has to be reported to . This leads to an extra amountof throughput time .
How is Requirement Management conducted now?Since November 2006, BUAM have been using the Requirement Traceability Matrix to increasethe visibility in the requirement management process, which has been created by the AM vendor.By this way, the interrelationship between different requirements can be detected and potentialproblems are early discovered .
At this moment the requirements are only stored in the RDD, which is often not centrallycaptured . Further, Test director is used for documentation of all test cases, test scripts and formanaging of all raised defects/issues during the test phases . This tool is also used for trackingchanges made to existing requirements .
What are the tools that BUAM are using?The following tools will be used to manage and track the project . Microsoft Project for projectplanning and for recording the hours spend in the different phases of the PDLC . As described inthe part above, Test Director is used to track changes and to execute a certain form ofRequirements Management .
Figure V.5 : Methodology (PDLC) Projects BUAM
)------------
99
Techniw/1 snMn. ..i [ ~ ~ ~ ~1 Usen
1------------ -----------------------------------------------------------------------------1 Vendon-
Narves! AD1
1i
Vendor-1 symphony
11----------- --------------------------°--------------------°------------------------------------------------------°-------------1 n
-AchiNRua1 Team
1 n .1 Securfty
Team1
______________________________________________________________________________________________________________________------------- -
1 GPO
11
Figure V.6 : Requirements Engineering Phase BUAM (Part A)
Figure V.7 : Requirements Engineering Phase BUAM (Part B)
1-7771 Vendor- ~ ~ -r,t1 Symphony ~
,~~SY~:ytr+~rn~~i{jéf 1 ~
------------ ____~_1 1 -~--- = ------=--=-=--------~}_ ===---- ---- -I
[i i
!!Tj~
- -n ____________________________________________________ % ------4------------
Legend - j A,3i .+tie
~i~i~F7eíYY1h*~d . .- ^.FAí(aiy 7r~ .- NaAa~eR~er+É Fruéiàà .
100
4. Requirement Engineering in Business Unit Private Clients(BUPC)
This case study elaborates on the findings in Business Unit Private Clients in respect toRequirements Engineering .
What type/nature of Business Unit is the focus of the case study about?Business Unit Private Clients (BUPC) has been an independent business unit since 2005 . BUPCis a global business unit and is located in several branches throughout the world, like Luxemburg,Suisse, France, Germany, Singapore, Gibraltar and Hong Kong . BUPC aims to invest for privatecustomers . There are four different types of customers : Retail Bankers, Preferred bankers, PrivateBankers and Private Wealth Customers for a free investing capital above the 25 Million Euro .
What is the history of BUPC in respect of IT?BUPC is a relative small business unit. There are 45 IT-related employees, whereof 5 persons arebusiness analysts and there are 6 to 7 Program Managers . This BU was created after the Harvestand Symphony initiative. In 2005 Private Clients was a part of Business Unit Asset ManagementFor this reason, there is hardly a history of BUPC in respect of IT .
At this moment BUPC had to change their formal way of working in a broader extent than theother business units are doing this. Now BUPC is busy with their Application and Developmentand Management (ADM) Process . Now BUPC is also busy with developing a ProjectManagement Office (PMO) .
How is the Requirements Definition process integrated in the software developmentprocess?BUPC is starting with establishing a lifecycle methodology . This methodology has not aparticular name, as the other BUs have, but the methodology has the form of a waterfall model .At the other side, there are some elements of the lifecycle of BUNL in the lifecycle methodologyof BUPC .The Application Maintenance Vendor for BUPC is TCS . This lifecycle model is used now, butthe Management Team of Private Clients has not accepted this model yet.
Furthermore BUPC is not developing their internal software from scratch . BUPC is buyingpackages, which are customized by the vendor to the different branches . These branches representdifferent cultures with different risk profiles . For this reason hedge funds are wide spread in Asia,while in the Netherlands deposits are very popular .There are many small projects, which result from the hub structure BUPC has together withcustomizing new applications in the different regions .
How is the Requirement Engineering process inside BUPCFrom the business side a need is created to build a system . This initiative is been held to theAllocation Board of Private Clients, which is looking at these initiatives and are approving them .When the Board has given their consent towards the initiative, the initiative can be elaborated .This happens in the Quickscan .
101
Subsequently, in the Business Case, the Requirement Document is set up . One part of therequirement document is the IT part . The Business Analyst is translating the businessrequirements in IT requirements. The result is a PRL, which is a part of the business case.
For defining the requirements in the PRL, BUPC uses a waterfall model in which theirrequirements are defined . As mentioned in the previous section, BUPC doesn't engineer softwarefrom scratch, but is purchasing packages . For this reason, vendors are concerned in selecting apackage . For this reason, requirement selection concerns what kind of tool is necessary .The end result is called a Prioritized Requirements List . The prioritization doesn't follow theBUNL rule, but there are four different rules :
o Critical
o High
o Medium
o Low
These are the same criteria as described for BUNA .
Who are the key actors/partners?• Program Manager. The Program Manager is responsible to execute the Business Case in
the project.• Business Analyst. The Business Analyst is responsible for translating the business ideas
in requirements for the PRL . There is no strict distinction between a business analyst ofthe business and the IT in this respect . The Business Analyst is also responsible forprioritizing the requirements in the PRL .
• Project Manager. This person is a project representative of TCS .• There is no explicit Requirement Manager
What are the biggest problems in managing requirements?In summary BUPC have the following problems :
• In the situation before September, the Business Case was sent to TCS . TCS had no ideawhat to do, which incurred a large amount of costs . Now Business Analysts aretranslating this to the AM vendor TCS .
• De business does not define their requirements properly . In this way, requirements arebecoming ambiguous resulting in components that not reflect the demand of the business .
• The throughput time of the phase where vendors are interacting is too high . The reasonfor this is that TCS lacks the contextual knowledge and the technical knowledge . For thisreason they are asking the help of a third party to solve these problems .
• There are hardly any possibilities to reuse components due to the new situation after theHarvest & Symphony initiative .
102
• The Functional Requirements are causing the most problems, as every region hasdifferent wishes, which reflect cultural aspects .
What are the tools that BUPC are using?BUPC is not using a tool at this moment due to its immaturity in requirement engineering andmanagement. Program managers are only using Microsoft Project, and only in a small extent .In BUPC there are too many tools at this moment, instead of one good tool .
103
~~-~C)
~
~~
O-2
colN
~D~
4~
o+-) M)
W~
~C~
~c á
en8,
~ c
WLL U
5 ~
p8 á
~ U
~ W
cc L
£ U
r m
t
cm
Z
2~UI
NÓó.~~W:sw~
Eó W~ E y ~
. y y
w ~ ~ W ~
W
ó ° $ °m
~ mal
W E •-
G ~ ~ ~~~`i~ ó ~ ói,~c É
~¢?p¢ ó ¢
N 6 ~ Ó(7 O C~17 ~
~ y G
~.C ~ r9 W O p =
~ ~ •
.-~', y T C~
2W
C~ G ~ W p~~,q~
Wg
= W
«W >1
É~w ~ó
41
c~~ ~ °~~ dá
d W N. a W W a,~,
=W
> ~ ip/[5 ~ii ~ c
.ó c~g 92
paN~ p
~ÓE Ó
9:SS
r-C
=L
'° G Ó
° > °á
9 9
pM
~~
.p p C
•~ Q~•€ f¢i W~ F,=
f p¢i M~7
Íi1U~¢ 000 v
O `~W~~
~~iÉ5
2bfEri's
1
€g v
r-Zg "~y
~~ C m GQ
9 h
S-2.0Co
?~X~+ ~2Á
Co
?~ ~ y m~
=~jL W
111lll~~~C
W9
.-SI~
9~
*~~.mo m m'T~ rn°' ~
2k~ m~ W
~~_a
6-
E ~~ ~ 2
~g m~~.9't
CLai2
~~ ~~° °~~~
5 3~~̀{p
~óE~~
~
m CCR
~ ~
; i:
2:
.0
~ ~p ~ ~t
lC ~N F ~ ~ O
OIUR' ~ LL_
wd~.w /0
~C~~ , y C ~ C a
m ~ tl)~ á C
N ~ m
~ E d
~LE~ m cc~
E'S5IHI
~0
Aóp u,3
y`0 ~ y y
o L Ó C~)N C Q " J
C d 71
9 2d~~~
E~mC ~
2á
~ ~ ~
0E0
E ~ ~',ó 7 ~ ~
P2
y~ 3í °
yy~ ~ v E
Q~9'5
aw
L ÍO C Ol~ N 9 N N 7 g~ ~~- ~ g C
p~ ó C pC C~~
Ul L~a
R' C '7 7 N K N~
2y 7 a ~7 O 'E Ó
.T`
, WN N y y
`~ ~ N
L~ d C y O N Ó f`~q L U Ó
d~
- O - ~ W N y '
5.
y U fp C
`ON/j W t71 tff741~J11 g'~ ~T ~ m°°1 ii
a tiiQ m g a
a m ~o a~5 Q d °$~Lo
o:m a,.- m q?
> n ~ 5
~ F a a'ó ~ W 7 w
p. O' T~ Y V L ~•-~ -
.7 T ~ ~ Lj. C ~ ó g ' ó
~ N t
.y fC0DC -" ~ c~ a á
5d)V v v s N c
p~m
2Ta
C -8 C,
LO)~ N ~ ~ r7 C
-uN
W1C ~ N Ó t/i
y cp N a in y V ÓI
•~ 0 9 d~~
.-sy
:SC
Hra?~ámh
-s2W >F->m B~Q
r« ~
d~ LCL
W
~W(00 C LM
yd
C C ~S3 9L
~ o~ y E E
~c~~ E L rn~ 5
Appendix VII. Explanation Root Cause Diagram
This appendix explains the model that is represented in Figure 2 .4. This diagram provides anoverview of the different problems that are present in the BUNL, BUAM, BUNA, and BUPC andis likely to be a profound representation of ABN AMRO as a whole, since the case studies areselected in such a way that the results are representative for the bank as a whole . This appendixwill discuss the three categories of problems regarding Requirements Specification, RequirementsManagement and Global Interaction problems, according to the decomposition of Figure 2 .4 inthe report .
Requirements SpecificationThe problems regarding Requirements Specification are decomposed in the activities elicitation,analysis, representation and validation, which represent the usual phases in specifyingrequirements .In the elicitation phase, there is often a lack of available information. Often requirementsknowledge of former projects is not known resulting in situations where the wheel has to bereinvented multiple times . Sometimes it is also difficult to know where requirements knowledgeis stored. This situation is occurring relatively often in BUNA where every project has its ownstorage place. This storage place is called a Quickplace.During the analysis phase, there is often a lack of a continuous client vendor dialogue in whichrepresentatives from the business, IT and the vendors are sitting together and discuss theirproblems regarding the specification of requirements . As a result, stakeholders are not informedabout the situation of the other stakeholders . This decreases the level of analysis and negotiationthat takes place in order to strive for a solution that will be applicable for all stakeholders .Problems related to requirements representation are twofold : resource related and templaterelated . The knowledge of the ABN AMRO personnel shows some shortcomings in analytic skillsof setting requirements . Further, some employees had troubles with defining their demands inproper English . Further, many employees hadn't finished their training yet in order to specifyrequirements unambiguously. The knowledge of the vendors showed some shortcomings bylacking in some cases contextual knowledge . This problem can be contributed to the relative newsituation of offshore-outsourcing and working with software vendors, instead of IT personnel whowere working for ABN AMRO in that particular BU . Further, IT vendors lacked also technicalknowledge, which can also be attributed to the new offshore-outsourcing environment . Thesecond problem category related to requirements representation, is caused by the form of therequirement specification template. The narrowing down of high-level business requirements indetailed requirements takes often much more time than expected . Further the formulation ofrequirements in the template causes often problems, due to ambiguities . The changing structure inwhich requirements are presented to the AM vendor and the Test vendor, result in largerthroughput times for designing and implementing the system that has to be built . This problemgoes hand in hand with the next problem by the high amount of variations in RequirementSpecification templates .The last problem regarding Requirements Specification is a problem related to the validation ofrequirements. In fact, peer reviewing of requirements that are represented in the template could bebetter executed so incompleteness and inconsistencies of requirements could be prevented .
109
Requirements ManagementThe second problem category concerns the activities of Requirements Management . According tothe decomposition of Requirements Management, represented in Wiegers (1999), RequirementsManagement facilitates the activities as change management, tracing and tracking, and tooling .Further, tracing and tracking can be subdivided in project status monitoring, requirements reuseand traceability .Problems regarding change management refer to a unified change process and an unambiguousrequirements change template . Often the execution of changes in requirements result in longprocessing times due to the lack of an available uniform change process .A problem related to tracing and tracking of requirements is the monitoring of the project status .Due to this inability BUs can hardly estimate durations for setting requirements and as a result ofthis, they can't measure their performance . The second problem related to requirements tracingand tracking is the absence of reusing requirements; functional as well as non-functionalrequirements . Especially the reuse of these non-functional requirements can result in significantperformance increases and cost savings, due to its generic character . Next, the absence oftraceability matrices for specifying requirements has narrowed down the possibilities of trackingrequirements .Regarding the tooling there are two problems : employees are using tools in the wrong way andBUs show to have an absence of useful tooling for capturing NFRs .
Global Interaction ProblemsThe third problem category concerns Global Interaction problems among BUs of ABN AMRO .Next to the variation in maturity, there is a wide variation in used terminology regardingRequirements Engineering between the AAB its BUs . Due to unambiguous terminology, manyBUs use different names for the same person in BUs . For example, the title of RequirementsEngineer at BUNL is used as Business Analyst in BUAM . For a detailed overview of terminologyacross BUs, this paper will refer to Appendix VII .Further, BUs have different software development methodologies for developing applications .Figure 2 .3 in the report exemplifies this. The figure shows that every BU in the exploratory casestudies has its own software development methodology .
110
-
Ex~~
k~32n
"
1.s 1S
•y#.Q..
6 6
É É
€8 ZV
,E,~
Z~ 9 ~
ZE4Z 4 .
f
IIiI~sIIIq -
I
II
Cl
Appendix IX. Setting NFRs at ABN AMRO
This appendix provides a description how non-functional requirements (NFRs) are set during theRequirements Specification Process for ABN AMRO . The Requirements Specification processhas already been described in Appendix V, so this appendix aims to answer the followingquestions :
∎ What different NFRs do there exist throughout the organization?∎ Can these NFRs be classified in types of similar characteristic features?∎ When are NFRs set during the Requirements Specification process?∎ How can NFRs be retrieved throughout the organization?∎ Who are the different stakeholders in specifying NFRs?
The appendix ends with conclusions that are drawn .
Section 9.01 What are the different NFRs?According to Wiegers (1999), NFRs define constraints or restrictions that are placed on high-level business requirements, user, interface or functional requirements . They also define qualityattributes that describe the product its characteristics in various dimensions that are importanteither to users, testers or the system being developed .This definition about NFRs implies that NFRs have a wide variation in character . This makes itdifficult to consider NFRs as one entity with similar properties . Figure IX 1 provides anexhaustive overview of the different NFR types that are used throughout the bank . The NFR typesin Figure IX . 1 are a collection of NFRs that are used at BUNL, BUTB and BUNA . These NFRtypes are identified during the research and form the basis for the NFR checklist, discussed inChapter 5 of the report .
Availability The assurance that the information system is available to all users at the righttime and in the right place .
Capacity This requirement defines the expected volume of inputs and outputs as well asthe internal storage and processing volumes affected by this request .
Communication This requirement describes the requirements associated with any communicationsInterface functions required by this product .
Completeness The assurance that all input is processed .
Conversion This requirement organizes the requirements pertaining the conversion, when thenew system replaces (a part of) an existing system .
Correctness The assurance that input is correctly processed to produce consistent data setsaccording to the specifications .
Data Integrity Data Integrity defines requirements related to the validity of the data .
Data Retention Data Retention defines requirements related to the length of time data needs to beretained.
Degradation The ease and quickness to resume the core information supply at a lower level,after a malfunction that causes a lasting breakdown .
112
Economy The relationship between the performance level of the entire information supply(online and batch) and the total amount of resources used .
Hardware This requirement type specifies the limits on physical resources, such as memorycapacity, disk capacity, and processor power .
Legal, Audit, This requirement type organizes requirements imposed by other parties.Compliance Examples are legal or audit (as imposed by Group Audit) requirements .
Maintainability The necessary effort to make specified modifications .
Manageability The necessary effort to operate and manage the information system .
Performance See Speed Requirements
Portability The ability to transfer software from one organizational, hardware or softwareenvironment to another .
Recovery The ease and assurance to restore the information supply after a malfunction.
Reliability The extent to which the information system remains free from malfunctions .
Resilience The ease and assurance the information system is recovering itself after amalfunction .
Scalability This requirement specifies the expected increases in size that the product must beable to handle .
Security The ability to prevent unauthorized access, whether accidental or deliberate, tosoftware and data and to ensure the confidentiality, integrity and exclusiveness ofthe information processed .
Software This requirement specifies the software applications that are required toDependency implement this high-level NFR .
Software Interface This requirement describes the connections between this product and otherspecific software components
Speed Response and processing times and throughput rates in online and batchinformation processing .
Suitability The presence and appropriateness of functions for specified tasks within theexisting or implied procedures .
Testability The necessary effort to validate the modified information system .
Timeliness The assurance that information is available for other processes within thespecified time span .
Transfer The ease and quickness to continue the core information supply in anotherlocation, after a malfunction that causes a lasting breakdown .
Usability The adjustment of the information system to the culture and the automationdegree of the organization it is meant for .
User-friendliness The ease for a user to learn to associate with the information system and the easefor experienced users to use the information system .
113
User Interface This requirement describes the logical characteristics of each interface betweenthe software and the users, and defines the software components for which a userinterface is needed .
Table IX.1 Different types of NFRs at ABN AMRO
Section 9.02 Can these NFRs be classified?This subsection answers whether it is possible to classify the NFRs that are listed in Table IX 1 intypes of similar characteristic feature. First, a classification example from literature is considered .Subsequently, NFR classification at BUNL is considered .
Literature about NFR classificationAccording to Kotonya (1998), NFRs can be classified in three different categories : product,process and external NFRs . Product requirements are requirements, which specify the desiredcharacteristics, that a system or subsystem must possess . At the other side, process requirementsare constraints that are placed upon the development process of the system . Finally, externalrequirements are requirements that are placed on both the product and the process and which arederived from the environment in which the system is developed, such as legal constraints . Thisclassification is depicted in Figure IX .2
1MnrFunctlam+^MUiMMiRtl
LkUrary
MS/uiiRAlq"
Implep.qnteebn .iequ40eryntte I,
aIFftftdoe.qur~ro
rauimmsnaFMde[i e~q.:iM19mL
IWsa611My raquiMmWp
ft447FIy +rqL: wrrm &
& lfaty raquliamwqs
ER6eiercp "IOamuame
1Lapal
eortriralma
&ammkaarariralme
Imorapaaoiiiy ~nqui,p~mnim
fhrk nnewm raquaemr+oe
crrmMiy .nqerr.ms,ma
Figure IX.2 Classification of NFRs (Kotonya, 1998)
NFR Classification at BUNLFor convenience sake, his subsection looks whether NFRs that are used at BUNL can beclassified easily . At BUNL three different types of NFRs can be distinguished during NFRspecification : Business related NFRs, IT related NFRs, and Service level related NFRs . Businessrelated NFRs contain NFRs like performance, security, availability, user-friendliness et cetera . ITrelated NFRs contain hardware and software constraints . Service level related NFRs containdocuments with scenarios in what way vendors like IBM, TCS and Infosys can keep the systemrunning .
A further decomposition of NFRs can take place, by decomposing all business NFRs regardingFunctionality, Usability, Reliability, Performance and Suitability, as depicted in Table IX . 1 .Functionality refer to the extent the application meets it quality standards regarding correctness,completeness, security and timeliness . Usability related NFRs relate to the interaction with theuser. Reliability related NFRs relate to the extent the application to be built will not fail .
114
Performance NFRs seem to be straightforward, while the Supportability NFR enhances theapplication can be managed and maintained in a proper way . However, three NFR types are notmentioned at this moment: conversion, hardware/software and compliancy. Hardware/softwareNFRs are IT related NFRs, while the compliancy NFR is externally imposed . According to manyexperts, conversion NFRs are difficult to fit in a structure and are not used that often.
Functionality: Correctness RequirementCompleteness RequirementSecurity RequirementTimeliness Requirement
Usability: User-friendliness RequirementAvailability RequirementSuitability RequirementUsability Requirement
Reliability: Reliability RequirementResilience RequirementRecovery RequirementDegradation RequirementTransfer Requirement
Performance: Speed RequirementEconomy Requirement
Supportability: Testability RequirementMaintainability RequirementPortability RequirementManageability Requirement
Table IX.2 Classification for business NFRs at BUNL
In line with the classification that was made in the beginning of this section, table IX .2 comprisesthe business related NFRs . IT related NFRs are hardware and software NFRs . Service level NFRsare likely to comprise IT related NFRs like hardware and software NFRs, together withsupportability NFRs .
However, the classification of Table IX .1 is subjected to the interpretation of the composer andhardly unambiguous . For example 24/7 availability is a NFR that originates from the business . Inorder to realize this NFR, the system has to degrade to a lower level when a malfunction occurs,should enough capacity on a server and should be reliable . In line with the classification of TableIX.2, availability reflects both the NFR type Usability, as well as the NFR type Reliability .
In conclusion, NFRs have many interdependencies between other types, which results in the factthat an unambiguous classification is impossible to make . For this reason, high-quality NFRshave to be specified in concrete, measurable and unambiguous terms .
Section 9.03 Defining NFRs in the Requirements Specification ProcessDuring the software development lifecycle, the Requirements Specification process is establishedin an iterative way. The objective of the Requirements Specification process is to deliver adocument of validated requirements. This requirements specification document consists of user,functional and non-functional requirements . Appendix I shows this Requirements Specificationdocument for BUNL: the Prioritized Requirements List (PRL) . When the PRL is approved by all
115
the stakeholders, the PRL is baselined and will go to the next phase in the software developmentlifecycle.
Generally, the Requirements Specification process comprises three iterative phases : the "why",the "what" and the "how", as depicted in Figure IX .3 . In the "why" phase, the high-level businessrequirements are identified, which determine the scope of the system to be built . In the "what"phase, all the NFRs are defined, together with the user, functional and interface requirements . Allthese Requirements are captured in the Requirements Specification document. Finally, in the"how" phase, the requirements are detailed out in such a way that the design of the application isunambiguously understandable for the Application Developer (AD) vendors .
The Requirements Specification process for NFRs follows the same way . The high-level businessrequirements define the scope of the system to be built and will form the input for capturing allthe NFR's during iterative process 2 . After capturing all the NFRs in the RequirementsSpecification document in the "what phase", it is clear for the AD vendor what the NFRs mean .The meaning of these NFRs is considered as standard knowledge that need no further detailing .However, NFRs for which multiple solutions are defined in the "what' ' phase, have to be furtherdetailed in the "how" phase .
Iterative process 1 : Identify High-level Business Needs
ative Process 2 : Derive User, Interface,onal and Non-Functional Requirements
I.jxI.&EIterative process 3 : DefineDetailed Requirements
How?
Figure IX.3 Iterative Requirements Engineering process (ABN AMRO Group, 2006)
According to Figure IX.3, all NFRs are set in Iterative Process 2. This process is highlighted by ablue circle .In conclusion, it is extremely important that the high-level needs are translated in the mostexhaustive way to iterative process 2, in which the setting of NFRs takes place . For this reason, asubset of high-quality NFRs reflect totally the high-level business NFR .
Section 9.04 Where are the different NFRs located?In Section 9 .01, the characteristic features of NFRs were discussed . One of these features was thewide variation of NFRs between each other . Due to this characteristic feature, NFRs aredispersedly located throughout the entire organizations . Generally, the Requirements Engineer ofa BU is responsible for setting NFRs in a Requirements Specification document. Section 9.05
116
elaborates further on the stakeholders for setting NFRs . Next, the locations from where NFRs areretrieved are listed :
• External imposed NFRs like compliance NFRs are derived from policies and regulations,like SOXA. These NFRs are stored in the ABN AMRO Instruction Manual (AIM) . Thisis a repository on the intranet where a numerous amount of policies and standards that areapplicable for ABN AMRO are documented . Besides the storing of compliance NFRs,AIM also stores NFRs regarding security and usability .
• Several NFRs find their basis in Service Level Agreements (SLAs) . SLAs are agreementsimposed by the (BU of the) bank to which applications has to agree. NFRs based onSLAs are Speed (The response time for a single page must not exceed 1 .5 secondsexcluding transport), Availability (24/7/365 availability, downtime of 1.0 % per monthprime time and 2.6 % outside prime time permitted) and NFRs related to the Reliabilitytype (99 % of the screens should contain actual information during prime time) .
• NFRs related to Security are retrieved from the Systeem Basis Toegangsregeling (SBT)Intranet . Some Security NFRs are also retrieved at AIM . An example of a Security NFRis : The application will use J2EE security on the level of URL's .
• IT related NFRs like hardware and software NFRs are located in manuals that are set upby Infrastructure vendors (IBM) . These manuals describe the regulations towards thecapacity of servers and other hardware constraints and lay down to which criteria thesystem has to meet . The process for collecting these NFRs should be considered as atime-consuming task For example : on a single Power 4+ CPU at 1.5 GHz (IBM P-series), the solution should be capable of handling at least 20 dynamic requests/secondwhile meeting the performance target of a maximum of 0.5 seconds for the entire request.
• Besides hardware and software NFRs, NFRs that relate to the Supportability type are alsolocated in manuals that are set up by an Infrastructure vendor (IBM) or the ApplicationDevelopment and Maintenance vendor (TCS and Infosys) .
• Many NFRs originate directly from specific business demands . Most of these NFRsdefine how the system should respond to the client ; NFRs of the usability type . Anexample is the following: if Internet Banking is delayed, but still operates within theaccepted maximum delay, then it is very important that feedback about this delay is givento the customer.
For BUNL, many NFRs that are gathered during the execution of a project before are stored in astructured way by the CARE tool Caliber RM . Appendix XI provides an overview how this toolis used during Requirements Specification .
In conclusion, due to NFRs wide variation in character, it is extremely important that NFRs arestored at locations where they can easily be retrieved . Further, NFRs have to be written down in aproper format, which enhances their reusability . If both these criteria are met, all NFRs can bereused in a BU, according to several process quality experts .
117
Section 9.05 Which Stakeholders are involved?As stated in the previous section, NFRs are dispersedly located throughout the organization. Twopersons are extremely important to gather the different NFRs : the Requirements Engineer and theSME Requirements Engineer .The Requirements Engineer has to gather business related NFRs that are located throughout theorganization. The SME Requirements Engineer capture IT related NFRs that are mostly stored inmanuals.This is a time consuming task, although it depends on the way the NFR knowledge is stored .These two Requirements Engineer can be considered as a "spider in the web" by communicatingwith all the different stakeholders for setting the total set of NFRs . Figure IX .4 gives an overviewof the other stakeholders at BUNL for setting NFRs :
DS Non-functional Requirements Ambassador User, Project Manager Business Visionary, Advisor Ketenregisseur, Visionary, Advisor User,in PRL, Requirements User, Business Operational Control / PO Business Architect,- Business part - Engineer Business, Architect, IT Business Analist,
Business Test Business Analist, Requirements ManagerAnalist, Requirements Business, BusinessImplementatie Manager Acceptance Manager,Diensten, AD Business, Test Manager, ProjectVendor, Test Business Manager IT, SMEVendor, Acceptance Design, SMEInfrastructure Manager, Test Requirements Engineer,Vendor, Fast Track Manager, Project Project Team, ProjectProvider Manager IT, SME Portfolio Manager
Design, SMERequirementsEngineer, ProjectTeam, ProjectPortfolio Manager
D9 Non-functional Requirements SME Project Manager IT Test Manager, Test Manager, S&Ain PRL, Requirements S&A Enterprise Enterprise Architect,- IT part - Engineer, SME Architect, F&OC, F&OC, SME Design,
Architecture, SDM, SME Design, SME ApplicationAD Vendor, AS SME Application Technology, Services ITVendor Technology,
Services ITD10 Non-functional Requirements SME Project Manager Business, Test Manager Services IT Test Manager, SDM,
in PRL, Requirements Project Manager IT Infrastructure Vendor,- Service Level part - Engineer, SME Fast Track Providers
Architecture, SMEApplicationTechnology, SDM,InfrastructureVendor, Fast TrackProviders
Figure IX.4 Stakeholders in setting NFRs at BUNL
At first sight, setting the business part of the NFRs looks the most complicated as manystakeholders have to be consulted. The test manager has to look if the application can actually runand meets its standards. Further, the IT application has to be embedded in its new IT environmentavoiding conflicts with the existing IT architecture .
Section 9.06 ConclusionsThis appendix has described the way the Requirements Specification Process deals with NFRs .At the end of this appendix, several conclusions can be drawn for setting NFRs at ABN AMRO,according to the five questions that were stated in the beginning of the appendix .
118
• What different NFRs exist throughout the bank? NFRs vary widely in character. For thisreason 31 different types of NFRs are identified, reflected in Table IX 1
• Can NFRs be classified? NFRs are impossible to classify unambiguously since NFRsinteract with each other constantly. This appendix has tried to decompose NFRs as properas possible. However, NFRs affect each other . In fact, a standard that enhances theusability of the system to be built (J2RR compliant) can be the same standard forenhancing the security of the system . Since this ABN AMRO standard affects more thanone NFR it is difficult to assign this NFR to one particular type .
• When are NFR set during the Requirements Specification process? NFRs are set duringiterative process 2, together with the setting of functional, user and interface NFRs . It iskey to translate the high-level business need as exhaustive as possible to the NFRs thathave to be set in iterative process 2. If this step is properly executed, high-level NFRs arecreated .
• How can NFRs be retrieved throughout the organization? NFRs have to be retrievedthroughout the entire organization. Due to their wide variety in character, NFRs arestored in a dispersed way throughout the organization. When NFRs are captured in theRequirements Specification document explicitly and if they are not stored in a dispersedway, NFRs can be reused extensively .
• Who are the different stakeholders in the organization for specifying NFRs? Two mainstakeholders in the organization execute the gathering of NFRs : the RequirementsEngineer and the SME Requirements Engineer . However, the gathering of NFRs affectsmuch more stakeholders .
119
Appendix X. Methods used for deriving a conceptual modelfrom literature.
In the literature a number of approaches are described that formed the basis for constructing theconceptual model. First, this appendix will describe more profoundly the existing methods forderiving directly a model from literature followed from the constructed design criteria .Furthermore, this appendix provides a description of two research fields discussed in Chapter 4 :Knowledge Management models and Quality Models . The spiral model of Kotonya (1998) forselecting a specification model for NFRs is represented in appendix III .
Section 10.01 Existing Methods for NFR reuseThis section will give an example of the existing methods that were initially used to derive amodel from literature .
SIRENSIREN (SImple REuse of software RequiremeNts) by Toval et al . (2002) is a method forRequirement Specification based an requirements reuse . The purpose of development withrequirements reuse is to identify descriptions of systems that could be used (either totally orpartially) with a minim al number of modifications, thus reducing the effort of development .Although a lot of more complex techniques for reusing requirements exist, as the Cybulskiclassification (Cybulski, 1998), the SIREN proposal for requirements reuse emphasizes simplicityand it is therefore more practical .
SIREN conforms to the most well-known software engineering standards for requirementsspecification . Requirements have a textual format, but can include any kind of objects, ascomplementary information -for instance tables, or schemas of any type . Siren encompasses aprocess model, some guidelines, techniques and tools . The guidelines that SIREN providesconsists of a hierarchy of requirements specification documents together with the templates foreach document . These serve to structure a reusable requirements repository.
According to the design criteria, the SIREN approach has the form of a knowledge managementprocess and forms a part of the Requirements Specification process . However, the model is notdesigned to deliver high-quality NFRs, since hardly any attention is paid to this aspect .
Cybulski Classification (1998)The Cybulski classification (1998) presented an approach to reusing software requirements thatfocuses not on the syntax of the requirements specification formalism, nor on the semantics ofreusable artifacts, neither it looks at the knowledge contained in the requirements . Instead itdescribed a method of requirements reuse based on the structural properties of the requirementsdocuments themselves and the processes used in their production . The method aims to beindependent of the syntax and the semantics of the requirements texts, hence, it should be equallyapplicable to both formal and informal statements of need . The method offers several differentways of reusing requirements texts and their associated artifacts, all described in terms of patternsin requirements reuse . The patterns also provide some guidelines to practical approaches ofautomating requirements reuse .
120
However, due to its purely focus on patterning in requirements reuse, the Cybulski classificationdoes not meet the knowledge management aspect for designing the conceptual model . Further, themodel does not meet the criteria for delivering high-quality NFRs .
Reuse based process of Kang et al. (1992)Kang et al (1992) have developed a reuse-based software development methodology . Themethodology is based on a life cycle model with refinement of each phase to identify reuseactivities. The reuse activities that are common across the life cycle phases are identified as : 1)studying the problem and available solutions to the problem and developing a reuse plan orstrategy, 2) identifying a solution structure for the problem following the reuse plan, 3)reconfiguring the solution structure to improve reuse at the next phase, 4) acquiring, instantiating,and/or modifying existing reusable components, 5) integrating the reused and any newlydeveloped components into the products for the phase, and 6) evaluating the products . Theseactivities are used as the base model for defining the specific activities at each phase of the lifecycle. This methodology focuses more on identification and application of reusable resourcesthan on construction of reusable resources, and some enhancements in the construction aspectmight be necessary to make it more complete .
Regarding the imposed design criteria of Table 4 .1, the reuse-based process developed by Kang etal. (1992) supports the knowledge management aspect of the conceptual model to be constructed .However, Kang et al . (1992) concentrate solely on the specification of functional requirements,rather than on NFRs. Furthermore, this model does not stress the importance in their model todeliver high-quality NFRs . Instead, the model is purely based on the enabling of the reuse offunctional requirements .
Model of Cysneiros et al. (2001)The framework of Cysneiros et al . (2001) aims to integrate NFRs into conceptual models . Thispaper aims to capture these NFRs in the very early phases of the software development process .The framework presents to integrate NFRs into the entity-relationship models and the object-oriented model .
This method of setting NFRs stresses the importance of high-quality NFRs by setting themrelative early in the Requirements Specification Process . For this reason, this method supports thedesign criteria Quality . However, the result of the model does not support a process-orientedmodel reflected in the Knowledge Management criteria as well as in the RequirementsSpecification criteria. In fact, the eventually constructed model is static by integrating NFRs intothe entity-relationship diagram and the object-oriented model .
Section 10.02 Knowledge Management ModelsThis section will provide an example of existing knowledge management models according to thedesign requirements imposed in Table 4 .2 of the report.
Generic Knowledge Management ModelAccording to De Jarnett (1996), knowledge management comprises knowledge creation, which isfollowed by knowledge capturing and knowledge interpretation, knowledge dissemination anduse. However, Quintas states (1997) that knowledge management is the process of critically
121
managing knowledge to meet existing needs, to identify and exploit existing and acquiredknowledge assets and to develop new opportunities .Basically, the generic knowledge management model can be represented as a continuous cycle .The essential components comprise knowledge creation, capture and dissemination (e .g. sharing).
knowledge creation
knowledge capture
knowledge dissemination
Figure X.1 Generic Knowledge Management Model (De Jarnett, 1996)
According to the design requirements for selecting a knowledge management model, the selectedknowledge management model has to have a process-oriented approach, has to be continuous andcyclic, has to produce explicit knowledge and might have experience with software development .The generic knowledge management has a process-oriented approach as well as continuous andcyclic. However, the model does not have experience in the Requirements Engineering field .
Knowledge Management Model of Demerest (1997)A traditional knowledge management model is the model of Demerest (1997), which is depictedin Figure X.2. The model can be described in the following way :Firstly, the model emphasizes the construction of knowledge within the organization . The modelassumes that explicit knowledge is then embodied within the organization, not just throughexplicit programmes but through a process of social interchange . Following embodiment there isa process of dissemination of the knowledge throughout the organization, resulting in the(economic) use of the knowledge .
rJWXWPc enc
O
cas~tu 'caai
U,e
Figure X.2 Knowledge Management Model (Demerest, 1997)
This model does not assume any given definition of knowledge and has a more holistic approachto knowledge construction. This suits the current situation of ABN AMRO where NFRknowledge is not constructed in one given definition due to its variety in character . Furthermorethe model is cyclic and can be considered as an elaboration of the generic knowledgemanagement model . Besides, the model has a process-oriented approach, because the emphasis of"working smarter" by reusing existing knowledge is depicted in the model by a double arrowbetween "knowledge dissemination" and "use" .
122
However, a potential drawback of this model is that the model is not total cyclic. In fact, the solidarrows or main flow form a limitation implying that recursive flows are less important . It alsoimplies a rather simplistic process-oriented approach, while in reality the flows of knowledgetransfer are extremely rapid and circulatory (McAdam et al ., 1999) .Furthermore, this model does not seem to have experience in the field of software development(Demerest, 1997) .
Section 10.03 Quality ModelsThis section will provide an example of existing quality model according to the designrequirements imposed in Table 4.4 of the report .
The House of QualityThe QFD framework, also known as the "House of Quality", uses four "houses" in assessingquality, and is depicted in Figure X .3 . The first house links customer needs to design attributes .Design attributes are engineering measures of product performance . For example, a computercustomer might state that he needs something, which makes it "easy to read what he is workingon". One solution to this need is to provide computer customers with monitors for viewing theirwork. Design attributes for the monitor is for example the physical measurement illumination ofalphanumeric characters. The second house of the QFD framework is linking these designattributes to the actions the firm can take . For example, a product development team can act tochange the product features of the monitor such as the number of the pixels or the size of thescreen . The third house of the QFD framework links the actions to implementation decisions suchas manufacturing process operations. The final house, beneath in the QFD framework, links theimplementation (manufacturing process operations) to production planning (Griffin, 1993) .
The QFD approach can be used in multiple ways . In theory, the goal of a House-of-Qualityanalysis is to specify target values for each of the design attributes . However, different teams usethe house in different ways . In some cases it is central to the design process and is used to makeevery decision, in others, its primary function is communication, and in still other others formalarithmetic operations provide formal targets for the design attributes (Griffin et al ., 1993) .
The QFD framework enables an organization to "build" quality into the product in the earlyphases of the software development process and to enhance the development process fromconcept to the operations (Govers, 1998) . In fact, QFD is driven by the concept of quality andresults in the best possible product to market, rather than being a control tool . Furthermore, theQFD framework has proven to be especially beneficial in the early stages of productdevelopment .
The QFD framework also has some drawbacks . First, the possible complexity can prevent the useof shortcuts and can result in a loss of enthusiasm, ideas, confidence, or resources over time .Finally, it is used to identify relationships based on different viewpoints . This identification ishard because requirements are described using vague terms, analysis is performed on a subjectivebasis, identifying relationships is time consuming, and it is difficult to reach consensus onrelationships (Zaim & Sevkli, 2002) . Besides the QFD model has no experience with softwaredevelopment, which makes it difficult to select this model according the design requirements ofTable 4 .4 .
123
~esignAttributes----- ,,,, Bwa1
Customer Needs(R00-800 inhtprprphy)
OLApITY Q!IlRe!!6-1-~iy
t
Relationshipsbetween
ee.aa.s .ae"aF .L+ex ."Oirt t" " Q FeR M
1 Customer Needsel!. b
_ Liand NRY7 Pilo 16M á"p EYF e.IOR Ta #!ue slaT8T.a1N PLIlR!! p1"be1CF/M!
tOWOaLN!lYaLlNFL
~F~eS1gnV' yV~`ym~r
.~~
Attributes Pnrc:eptiunscosts and Feaaióàrily
ImPortances "~ngineer3ng"Measures
Figure X.3 The Quality Function Deployment Model (Akao, 1987)
FMEAThe Failure Mode and Effect Analysis is a well-known systematic approach to identify potentialfailure modes and their root causes proactively . This tool helps to identify, characterize andprioritize risk. In a group session potential causes leading to failures are identified andsubsequently a risk priority number is assigned. The risk priority number is the product of thescores on three dimensions : likelihood, severity, and detectability . These three scores aredetermined according to an assessment matrix . As a result, a list of design issues that requirescorrective actions is obtained.
In comparison with the aforementioned QFD framework, both frameworks are used as qualityprocess tools in product development . The difference is that QFD is used during the early phasesof the lifecycle, while FMEA is used in the latter phases of the lifecycle (Ginn et al ., 1998) .Furthermore, the FMEA has a substantial track record in the production development, like theautomotive industry, rather than the software development .
CMMFurthermore, many initiatives regarding software development quality, considers the qualityaspect in a static approach . A striking example is the use of the Capability Maturity Model(CMM), developed by Carnegie Mellon's Software Engineering Institute. Every component isscaled by addressing it to the Capability Maturity Model (CMM), developed by CarnegieMellon's Software Engineering Institute. It examines six dimensions, rating each on a scale of 1(lowest) to 5 (highest) . In order to obtain a maturity level 5, all attributes must have the valuesdescribed in the last column of
Although this model aims to improve the quality of organizational processes in the organization,this model does not fit to the design requirements represented in Table 4 .4. Due to its afterwardsquality measuring and its static approach, the CMM model will not fit to the design requirementsto be eventually a part of the conceptual model that will be constructed .
124
F~ assessmeasNx§evi~vs.CamhirAaaus ~~Ew~ sáabqg p~iT-~ P~R e~atpe~ sm~$g~ C10Il4d
IT 6RVe<eeIbt mIDnqemeat$~tl76~ C~b~S~. d70~LHR O~
9us kess pe3wGCa Od TI V~Role afiT m sRr~c imsaaessP~5~ pat-, aiá-.ApW"7}Am~
Ir prog- R~W~SB oeBR~ s~c6owiam
Trashtuaed enablerfdsmer,eaeae cmilS&mdiAdS ffityCïlbvdmA1Cb11}et=31 iLWeg[Ahen
FLmCdond o[pón2ahmEampmse
km-eunspazeeA]1CWeCU.IIdIl u.Y1q8LE6Cy,filFSbiLtyrmto+mnum, ernEepeueurAwIA)CHS Q€PMM
Figure X.4 CMM model
,d~ vatinked
aPM~Y n-M
Not P~pactised
IT &*es risk v&h little EGNaCdAd-hDEC~ gjmïninnnm
None
TCad1~(E.E 1CCD7emOg„enwii)Natie«#d-becNo factnal we~
NowDiscawagedk the budms
C~ and c~Ras~m chapNoneNetteNo peagaei
~Exaended ao essoemal~ paeinesExeeaded~so e~ pam ee :Hw~, ua¢mar, & rl,vearissEg~éo0~ pale,esxB.auà®elype~d withP~R,a~perkwda~ ~d
I~acaase. e~1~acaow, e~Gio ~m CEO, fieder~iau~ceaéex, pmafut ceew$~aahrpa~iiV"edrled [lè9i Er
iT co-ddaptS 87f$ buum6
Co .tidapliw " ów~
R?sks & e~ slwd
CrmrimMC Mv~V~ partaoershrpAt theCEO leME~ XUOE,b~ 6sn~ diiverenableq16G2FeD~ Std~EvolwmAhpa~
~EeBd
$tl9~[el~8ICf5E6CEeá2With all p~
9QQSS dm ~dmC18CkOSBThe mmAu mxuiM ied~ cto
b~High. rDcusedAca®ss the eemetprifeA,cwss the emoe[pnseEtëecuve program ~gaedra~
125
Appendix XI. Caliber RM
This section will elaborate on the functionalities of the Requirements Management SystemCaliber RM. This tool is only used at this moment at BUNL and BULA, but has been referred inthis research several times . Four aspects of this system will be discussed :
∎ Managing Requirements∎ Defining Requirements∎ Tracing Requirements and the∎ Integration with other information sources .
Section 11 .01 Managing requirementsCaliber RM helps to control requirements management process and enables project teams todeliver higher quality applications . In an effort to detect and eliminate requirement errors anddeficiencies earlier in the development cycle, Caliber RM allows teams to fully define,manage and communicate changing requirements . Changes to requirement data such astraceability, status, priority and more are recorded and stored in Caliber RM its centralrepository providing reliable, up-to-date information for effective requirements-drivendevelopment and testing . Caliber RM also allows team members to compare project baselinesto easily manage scope creep and identify other factors, which may affect schedules andbudgets. And the support for reusable requirements ensures that project teams can build fromprevious experience and applications, enabling more rapid development and better use ofresources .
Section 11 .02 Defining requirementsWith Caliber RM, organizations can instill discipline in their development cycle through astructured requirements management process, minimizing the cost of reworks due torequirement errors, focusing team members on the project scope and decreasing thelikelihood of project failures and overruns. Caliber RM enables to define and manage allaspects of a project's requirements, from defining the requirements to assigning responsibleteam members, even tracking requirement relationships . By fully defining applicationrequirements in Caliber RM, a project team can focus efforts on requirements within theproject scope and ensure that critical requirements are met . By allowing project teams to fullydefine and record requirement data-including user-defined attributes, document referencesand verification information-Caliber RM enables earlier detection and correction ofmissing, contradictory or inadequately defined requirements . The result is higher qualityapplications that meet end-user needs .To promote communication among team members, Caliber RM allows all team members tocontribute their feedback on requirements through its group discussion feature . Comments arestored as threaded conversations by requirement, enabling you to easily review comments inorder to revise and prioritize requirements . Caliber RM its Web Access component provideseasy access to group discussion for those who may provide valuable input to the project, butdo not need fully functional clients. Caliber RM also allows individuals to be assigned toeach requirement to facilitate change notification . When requirements are added, modified ordeleted, responsible individuals are automatically notified via E-mail, ensuring that everyteam member is aware of the current state of requirements at all times .
126
Section 11.03 Tracing requirementsCaliber RM supports traceability of requirements throughout the development lifecycle to aidin impact analysis and requirement definition . Requirements typically can generate amultitude of additional requirements, and may even relate to requirements in other projects .Through the traceability matrix, you can easily see the impact a requirement change will haveon other requirements . You can also determine which requirements are not beingimplemented, and which requirements are outside the defined project scope .
Section 11 .04 Integrating with other information sourcesCaliber RM is closely integrated with Microsoft ® Word TM and Excel TM and allows users toview a requirement reference in context within the Caliber RM interface . Users can alsoimport requirements from Word documents to leverage existing requirement documentation .In addition, Caliber RM enables to establish multiple links to other files, such as screencaptures, spreadsheets and presentations, to guarantee that supplementary information isalways available.
A print screen of the interface of Caliber RM is represented in Figure XI . 1 .
®®~ esz~CU«ne~e
opr feaa .mr. ~b~i - ai ~ . ~. .
® 000 hWr Levd dehess RequFem.nts (BR)
EB Q 100 User R.quPoments (USER)El ZW N~ R~II (FUN)p Q 300Interf.ce Raqukanents (UF)
®Q400DetdYedRepArdneMs(DETALL)Q 900 AvdkbWkY ReQianxts (AVA)Q 901 COMP~ReWkanerRS (CODP)Q 902 CanpYmce Rapvercads (COMPLI)Q 903 Cammsbn RepWraments (CON)Q 904 Carre[tnesl Rel}iemMts (CORR)Q 905 DeQadeHm Raqhmmnts (DEG7!)Q 906 EcanwnVRe~(ECOfQ® 907 Xerdwme R .puk.ments (NW)Q 908 MattaFadkV RepWenats (MIN)Q 909 Md+ .9.e6YRV Requtaments (nuwG)Q 910 Poft~ Requterterts (PORT)Q 911 Recwery Raqilremalks (RECO)Q 913Re~RequkemaRS (RESI)Q 914 Spcvk9 Rep6ements (SEC) _Q 9t5 Speed RepWranerts (SPED) jrrmc,Q 916 SuRabIRV ReuirmieMs (RllT) ~Q 917 Testaó8ty Requrements (TEST)Q 918 Tmefnns Requrmieds (TIME)Q 919 Trarufa ReP~ (TRAMQ 920 Usahlky Reµiertents (USAR)Q 921 UW-(rendibss RaQUYemnts (USFR)
FP.VNOD
. . . x .. ... . ;.:r 't .:è.~ .. . .. ,~ ~ ~ .~,,.~k . ..
W,
Figure XI.1 Interface Caliber RM
e 1
127
Appendix XII. Logical Data Model
This appendix gives an overview of the reusable NFR repository that has to be developed whenthe comprehensive NFR checklist has evolved into a success . At first, the structure of therepository is described. Consecutively, the operationalization of the tool is described .
Section 12.01 UML modelAccording to stakeholders who validated the constructed conceptual model, a reusable repositorywould be very helpful for defining NFRs . The design criteria for this reusable repository to bebuilt were the following :
• The repository should have a clear and understandable interface, which enhances a properclassification of NFRs
• The repository should have multiple owners;
• The output from the queries that are set (i .e . NFRs) have to be appropriate for use .
In other words, the reusable repository has to be simple and effective . In order to specify thisrepository for which the criteria has been described above, the unified modelling language (UML)is used . UML is a general purpose modelling language that includes a standard graphical notation,which can be used to create an abstract model of the system . Figure XII .1 depicts the model thathas been formulated for the design of the reusable repository . This UML model has beendeveloped according to the following steps, which has been derived from Wagner (2002) .
1 . List candidate object classes. In this case it turned out that four candidate classes could beidentified:
a) A project is the ultimate motive to start reusing NFRs . For each project, theRequirements Specification document comprises a subset of NFRs as being a part of aparticular project.
b) External imposed documentation comprises a subset of sources, which form the basisfor deriving NFRs. This can be interrelationships documents to which applications haveto meet regarding their IT vendors, as well as external imposed regulations regardingLegal, Audit and Compliance . This documentation will not contain NFRs that areabstracted from Requirements Specification documents, as these are handled in a) .
c) A Non-Functional Requirement is the crucial entity in the reusable repository .
2 . Determine the attributes of each object class . The step specifies the exact data on every objectclass that needs to be documented . The results are presented in the in the object class table inFigure XII .1
128
3. Identify relevant associations . There exists a relation between the project and the NFR, andbetween the NFR and the external imposed documentation .
4. Add constraints. Multiplicity can be added, which state for the relation between A and B howmany B objects may be linked to A objects .
a) One project may have one to many Non-Functional requirements where one to manyNon-Functional requirements belongs to one project .
b) One Non-Functional requirement originates from one type of external imposeddocumentation whereas one source of external imposed documentation can have one tomore Non-Functional requirements .
NameNumber
-DescriptionBusineft Unit-GroupProject leader
belongs to
Nanáunclianal Requiremettt-Nameumber
1--' DescriptionOwner-BU&wmm Unit
has ProjectVersion[Date
belongs to
F.x't3em~al limposed DocumentationtUarneVescripti onType-SourceCArmer-Business U n it-VersionDate
Figure XII .1 UML Model for the reusable repository
Section 12 .02 Intervention PlanThis subsection will provide the prerequisites for operationalizing the UML model that isdescribed in the previous subsection. These prerequisites originate from interviews that wereconducted with concerned stakeholders . This has led to the following aspects that have to becovered in order to make the repository to a success . The central questions will be :
Which actions have to be undertaken before stakeholders are going to use the reusable repository?
129
This question can be subdivided in two aspects to be covered: the content of the repository (hardaspect) and how do we "sell" the use of the repository to our stakeholders (soft aspect) :
Hard aspectsThe UML model from the previous section forms the basis for constructing the reusablerepository . The comprehensive checklist, which has been discussed in the report, forms theoperationalization of the conceptual model adjusted to ABN AMRO.
The repository must have a substantial amount of high-quality NFR content, otherwisestakeholders will not use the repository . Interviews of different stakeholders revealed that arepository would only work if the content in it is reliable, complete and consistent . Due to theabsence of a NFR repository at this moment, there is no clear idea which stakeholders should beincurred. Generally, there are three different types of functions :
∎ Responsible resources for abstracting NFRs from Requirements SpecificationDocuments, putting them in the repository and updating these NFRs . This activity hasto be executed by owners of the NFRs who are responsible for the "RepositoryImprovement "-step, provided in the conceptual model . The reason for choosing forassigning ownership will be twofold . First, a substantial cots reduction is achievedsince no additional party has to be assigned for abstracting NFRs . Further, ownershipenhances the dynamic for visiting and using the repository . This will increase thelikelihood that the repository is actually used during Requirements Specification
∎ Resources who add external imposed documentation regarding NFRs to therepository. By this way, the repository will not consist solely on NFRs originatedfrom existing projects but will also consists of NFRs that will be used in future . Thiswill increase the total amount of NFRs in the repository, resulting in the fact that therepository will get a higher relevance in the total Requirements Specification process .This task will have the highest similarity with the task that experts are executing now .
∎ Resources who look after the quality of the NFRs captured in the repository . Thetasks that are described above are concerned with adding NFRs without having a totaloverview on the quality of the repository. For this reason, it will be extremelyimportant that the repository maintains to have a high quality by avoiding ambiguous,incomplete and duplicated NFRs in the repository. This task will also have thehighest similarity with the tasks that are executed by experts at this moment .
Soft AspectsThe last subsection provided an insight in the hard aspects for realizing the reusable repository bystressing that the content has to constantly up-to-date, together with assigning resources to theactivities that have to be executed. This subsection will discuss the soft aspects for realizing thereusable repository. Two aspects will be discussed:
∎ How can we "sell" our repository to our future users?
• How can owners recognize the mutual benefit for adding and improving the NFRs in thereusable repository, when they are using the repository?
In the remainder of this subsection these two aspects will be explained :
130
In order to answer the second question how to "sell" the repository to the intended users, severalstakeholders were interviewed during the validation of the constructed model . Many of thesestakeholders were not using a tool at this moment, nor were they sharing NFRs between eachother. It became evident that:
∎ Users must not have to learn how to use the tool, but the tool should explain it self to theusers;
∎ The output of NFRs in the repository has to be excellent ;
∎ Users have to be told by an employee with a high mandate in the organization that theyhave to use the repository in the future . In the past, this method has worked successfullyfor prescription of MS Project templates to monitor the time distribution of employeesduring a project .
Recognition of the added value for adding and improving information to the repository will beextremely difficult . In order to answer this question, this research has looked to similarrepositories inside ABN AMRO where owners of documents realize that repository improvementis important . After discussion with owners of the BIB 2 Project, which will be described in thereport, has revealed some preconditions for an active use of the repository is :
∎ Stakeholders must see that multiple parties are using this repository . The documentmanagement system CASCADE is widely used throughout the bank . This will give anincentive for new projects also to use this system .
∎ There has to be a continuous dialogue between the owners and the developers of therepository what aspects have to be covered so that owners will use the repository .
131
132
Contact Information
Benno B . WatermanLloyd Webberhof 963543 EH UtrechtThe Netherlands+316 41304026B.B. Waterman@student .tue .nl
TU/e Eindhoven University of TechnologyP.O. Box 5135600 MB EindhovenThe Netherlandswww.tue.nl
Dr. Ir. S . AngelovBuilding Paviljoen D03+3140 2472617
Prof. Dr. R .J. KustersBuilding Paviljoen Dl 6+3140 2474076
IfABN-AMRO Paalbergweg 21-23
1105 BX Amsterdamwww.abnamro.nl
Ir . P .J. M. M. PloumB1 18+31 20 6285518
B. SchreinerB 1 24+3120 3437847
134
Non-Functional Requirements Comprehensive Checklistgo
ABN-AMRO
Non-Functional RequirementsComprehensive Checklist
Version number 2.0Date 06-June-07Status DraftAuthors Benno WatermanOwner
Version : 2.0/ Status: Draft(06-June-2007) 135
Non-Functional Requirements Comprehensive Checklist
Document Management
ContributorsThe following persons contributed to this document :
1PABN-AMRO
FRamesh Devare PATNIChris de Jon BU Transaction BankingBert Dubbelman BU Netherlands
External/internal ReviewThis document requires the following External/Internal Reviews . Records of the appropriate reviewsare filed in the Quality section of the project control documentation .
NameBert Dubbelman I BU NetherlandsRob Hoolwerf BU Transaction Banking
ApproversThis document requires the following approvals . Records of the appropriate approvals are filed in theQuality section of the project control documentation .
Name Function Signoff
Version : 2 .0/ Status : Draft (06-June-2007) 136
Non-Functional Requirements Comprehensive Checklist
Revision History
IPABN-AMRO
Revision ~Numbor
R+avïs~date
iet~ry of eharvin
1 .0 11-5-2007 Initial version . n .a .
Input DocumentsA list of documents used as input in this document:
∎ Manual for Business Requirements and Software Requirements Specification forBusiness Unit North America, version 8 .1
∎ Non-Functional Requirements Document Best Internet Bank, BUNL• REM Requirements types for BUNL, version 1 .4∎ Non Functional Requirements example, BUTB∎ Mft Acceptance Criteria, BUTB∎ Non-functional Requirements Document Global File Transfer, BUTB∎ Non-Functional Requirements IBM AAB Account, version 2 .4, by H .Ranty and R .Schreurs
Reference DocumentsA list of documents that were used to construct this document as being a reference, and not as anactual input :
∎ Requirements Specification TCS AM Requirements∎ Requirements Specification IBM SLA Requirements∎ Requirements Specification IBM Infrastructure & Network Requirements∎ Requirements Specification IBM PSFT Requirements• EDS ABN AMRO Account∎ Nom-Functional Requirements EDS Draft by H .Ranty and R .Schreurs
Version : 2 .0/ Status : Draft(06-June-2007) 137
Non-Functional Requirements Comprehensive Checklistgo
ABN-AMRO
Table of contents
Document Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
1 . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..139
1 .1 Background and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1391 .2 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
2 . Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
3 . Detailing the Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
3.1 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1423.2 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1443.3 Communication Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1453.4 Completeness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1463.5 Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1473.6 Correctness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1483.7 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1493.8 Data Retention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1503.9 Degradation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1513.10 Economy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1523.11 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1533.12 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1543.13 Legal, Audit & Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1553.14 Maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1563.15 Manageability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1573.16 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1583.17 Portability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1603.18 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1613.19 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1623.20 Resilience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1633.21 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1643.22 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1653.23 Software Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1683.24 Software Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1693.25 Suitability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1703.26 Testability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1713 .27 Timeliness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1723.28 Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1733.29 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1743.30 User-friendliness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1753.31 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176
4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..177
5. Clarification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . .180
6. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Version : 2 .0/ Status : Draft (06-June-2007) 138
Non-Functional Requirements Comprehensive Checklist
1 . Introduction
01ABN-AMRO
1 .1 Background and ObjectivesThe objective of this document is to provide a comprehensive checklist for reusing Non-FunctionalRequirements (NFRs) by multiple Business Units (BUs). This document does not aim to replace theexisting way NFRs are set at Business Units . At this moment every BU has its own way of settingNFRs and its own way of classifying NFRs .This document aims to serve as a way to consolidate the existing NFR knowledge in ABN AMRO . Forthis reason, the NFRs that are listed in this document have been refined to serve general applicability,which means that these NFRs are not BU specific. Subsequently, BUs can add their own context to it .It is tried to make he decomposition of NFRs as extensive as possible to cover all the different NFRtypes.
This document will consist of two parts . The first part will provide operational definitions of the differentNFRs. The second part consists of a checklist if all NFRs are present and if these NFRs are capturedin the right way . Examples will be provided that can be used due to their generic applicability .Furthermore, the user of this document can determine if this certain NFR will be applicable for hisproject by prioritizing the particular NFR. In general, four prioritization levels can be distinguished :critical, high, medium and low .
This document will end by providing how BU-specific vendor NFRs fit in the classification of NFRs thathas been made in this document.
This document has tried to capture all the NFRs in this document as straight-forward as possible byavoiding unambiguous terms .
1 .2 AcknowledgementsBefore starting to use this document, I would like to mention the important contributions of BUNL,BUNA and BUTB . The work at BUNL has been the basis for the decomposition of NFR types and thedefinitions that are provided in this document. At the other side, the BUNA Requirements Templatewas extremely helpful for exemplifying many NFR types . This document is recommended to read due,especially for its extensive elaboration on NFRs . BUTB has provided many templates that provided anextensive insight in setting NFRs .
Version: 2 .0/ Status : Draft (06-June-2007) 139
Non-Functional Requirements Comprehensive Checklist
2. Non-Functional Requirements
ifABN-AMRO
This section will provide in an overview the definitions for the different high-level NFRs that arecurrently available in the Business Units of the ABN AMRO Bank
Availability The assurance that the information system is available to all users at the righttime and in the right place .
Capacity This requirement defines the expected volume of inputs and outputs as well asthe internal storage and processing volumes affected by this request .
Communication This requirement describes the requirements associated with anyInterface communications functions required by this product .
Completeness The assurance that all input is processed .
Conversion This requirement organizes the requirements pertaining the conversion, when thenew system replaces (a part of) an existing system .
Correctness The assurance that input is correctly processed to produce consistent data setsaccording to the specifications .
Data Integrity Data Integrity defines requirements related to the validity of the data .
Data Retention Data Retention defines requirements related to the length of time data needs tobe retained .
Degradation The ease and quickness to resume the core information supply at a lower level,after a malfunction that causes a lasting breakdown .
Economy The relationship between the performance level of the entire information supply(online and batch) and the total amount of resources used .
Hardware This requirement type specifies the limits on physical resources, such as memorycapacity, disk capacity, and processor power .
Legal, Audit, This requirement type organizes requirements imposed by other parties .Compliance Examples are legal or audit (as imposed by Group Audit) requirements .
Maintainability The necessary effort to make specified modifications .
Manageability The necessary effort to operate and manage the information system .
Performance See Speed Requirements
Portability The ability to transfer software from one organizational, hardware or softwareenvironment to another .
Recovery The ease and assurance to restore the information supply after a malfunction .
Reliability The extent to which the information system remains free from malfunctions .
Resilience The ease and assurance the information system is recovering itself after amalfunction .
Scalability This requirement specifies the expected increases in size that the product mustbe able to handle .
Security The ability to prevent unauthorized access, whether accidental or deliberate, tosoftware and data and to ensure the confidentiality, integrity and exclusiveness ofthe information processed .
Software This requirement specifies the software applications that are required toDependency implement this high-level NFR .
Software Interface This requirement describes the connections between this product and otherspecific software components
Version : 2 .0/ Status: Draft(06-June-2007) 140
Non-Functional Requirements Comprehensive ChecklistIf
ABN-AMRO
Speed Response and processing times and throughput rates in online and batchinformation processing .
Suitability The presence and appropriateness of functions for specified tasks within theexisting or implied procedures .
Testability The necessary effort to validate the modified information system .
Timeliness The assurance that information is available for other processes within thespecified time span .
Transfer The ease and quickness to continue the core information supply in anotherlocation, after a malfunction that causes a lasting breakdown .
Usability The adjustment of the information system to the culture and the automationdegree of the organization it is meant for .
User-friendliness The ease for a user to learn to associate with the information system and theease for experienced users to use the information system .
User Interface This requirement describes the logical characteristics of each interface betweenthe software and the users, and defines the software components for which auser interface is needed .
The definitions for describing high-level NFRs, listed in the table above, do not aim to impose that BUschange their way for structuring NFRs . This table aims to provide a clarification of all the different high-level NFRs that are used at this moment .
Version: 2 .0/ Status : Draft(06-June-2007) 141
Non-Functional Requirements Comprehensive Checklistgo
ABN-AMRO
3. Detailing the Non-Functional RequirementsThis section contains per high-level NFR examples and details regarding the implementation of therequirement in its environment . This will be represented by providing a checklist for each high-levelNFR .
3.1 Availability
Availability NFRs specify the factors required to guarantee that the information system is available toall users at the right time and in the right place .Two types of Availability NFRs can be distinguished :
1) NFRs that define what the availability should be . This can be established by measurable units,as well as by solely text. This includes requirements such as the following :
∎ Is there a maximum acceptable time for restarting the system after a failure?
∎ What is the acceptable system downtime per 24-hour period?
∎ When do the users in various locations need to access the system?
2) The second type of Availability NFRs defines what aspects should be covered to deliver theintended availability level, mentioned in 1) . These NFRs are the prerequisites of realizing theintended availability level and have a Technical or a Supportability character . This distinction ismarked in the table below by a white line . This includes requirements such as the following :
• What are the preconditions regarding a checkpoint?
∎ What are the preconditions regarding recovery?
∎ What are the preconditions regarding restart?
An overview of Availability NFRs is provided in the table below :
. 1W 'o PriorityAVO1 The application should be available for use 24 h per day, 365 days per
yearAV02 The application shall be available for use between the hours of « . . .»
am and « . . .» m, CST .AV03 Downtime permitted of «,,,»%, per month during prime time and
«, . .»% outside prime timeAV04 Retrenchment check on a brokerage order should be 24/7 availableAV05 The availability of the personal inbox application must be the same as
the availability of the « . . .»environment .AV06 «,, .» acceptable incident per « . . .» are allowed. This also includes
the applications in the test environments, which are part of the installedbase .
AV07 The batch processing should last at maximum « . . .»
AV08 For redirect-support the application must use the framework support thathas been adapted to support reverse proxies
AV09 A load balancing mechanism is used to distribute requests over theavailable web application instances to obtain business applications withan availability of « . . .» during daytime
AV10 The load balancing mechanism should support session affinity
ersion : 2 .0/ Status : Draft (06-June-2007) 142
Non-Functional Requirements Comprehensive Checklist*
ABN-AMRO
~`. 77,77,
AV11 An application must check the availability of services that are essentialfor the proper functioning of the application . The result of this checkdetermines the response to health check requests .
AV12 Within each application a health check must be implemented that isused by the load balancing mechanism to verify the availability of theapplication instance on the specific server
AV13 Implementation of a standard way of exception handling . An applicationshould check the occurrence of exceptions from the business services,and should fail a health check when these occur .
AV14 The repair time after a production disturbance must be known .AV15 The service times must be knownAV16 The maintenance window must be knownAV17 The disaster site must be usable in « . . .» % of daytimeAV18 In case of critical applications, support outside office hours must be
arranged A stand-byAV19 If the business requires stand-by, the contact persons for this stand-by
service must be known .
Version : 2 .0/ Status: Draft (06-June-2007) 143
Non-Functional Requirements Comprehensive ChecklistIV
ABN-AMRO
3.2 Capacity
The Capacity NFR defines the expected volume of inputs and outputs as well as the internal storageand processing volumes affected by this request . Include the number of users if applicable . Thisincludes requirements such as the following :
• The expected schedule of the inputs and outputs (e .g. the system shall create Report "xyz",once a month)
• State how the system should continue to perform over time as changes in volume or systemsize occur in order to meet a user need, such as growth or data migration
• Specify volumes of users and data the system will support ; this can be expressed as a profileover time .
A collection of Capacity NFRs are represented in the table below :
Ref nr Stmari#t Pd**
CA01 The system shall cater for « . . .» simultaneous users within the period from« . . .»am to « . . .»am . Maximum loading at other periods will be«. ..»users .
CA02 The system must be able to handle a peak load of «. . .» simultaneoususers with no more than a« . . .» second response time .
CA03 The system may not consume an amount of «. . .» system resources tofulfill user requests .
CA04 On a single « . ..» CPU at « . . . . »GHz (« . . .» series), the solutionshould be capable of handling at least « . . .» dynamic requests/secondwhile meeting the performance target of a maximum of « . . .» seconds forthe entire request (including backend time!) .
CA05 An application may not use more than « . . .» MB JVM-s aceCA06 A« . . .» Service may not use more than « . . .» MB JVM-s aceCA07 The system should allow for high parallelization . There shouldn't be any
bottlenecks or synchronized code blocks that reduce performance for at least«. . .» concurrent threads in a single JVM . However, in normal productionwe don't expect concurrenc to become this high
Version : 2 .0/ Status : Draft(06-June-2007) 144
Non-Functional Requirements Comprehensive Checklist1P
ABN-AMRO
3 .3 Communication Interface
Communication Interface Requirements describe the requirements associated with anycommunications functions required by this product . Include requirements such as the following :
• E-mail• Web browser• Network server communications protocols• Electronic forms• Define any pertinent message formatting• Identify any communication standards that will be used, such as FTP or HTTP• Specify any communication security or encryption issues, data transfer rates, and
synchronization mechanisms• Is the system using communications interfaces such as a modem or LAN?• Is the communication handled by your software or some other like operating system?• Is the communication protocols secured?• Is the data encrypted during transfer?• If data is critical, have provisions been made to secure in storage?
A collection of Communication Interface NFRs are represented in the table below :Ref. nr $conwio Priority
service
C102 e system should support «XML, EDIFACT, Swift, ISO 20022, FIXML»Thas message language
C 103
CI01 The system should support «, . .» (for example : Request/Reply,invocation, event drivenasynchronous/one way messages, stateless
communication
Version : 2 .0/ Status : Draft (06-June-2007) 145
Non-Functional Requirements Comprehensive Checklist
3.4 CompletenessCompleteness NFRs refer to the assurance that all input is processes .
An example of Completeness NFRs is provided below :
ifABN-AMRO
CM01 The documentation for the system to be built has to have a continuous up-to-date ness
CM02 The documentation has to be baselined before productionCM03
Version : 2 .0/ Status : Draft (06-June-2007) 146
Non-Functional Requirements Comprehensive ChecklistIP
ABN-AMRO
3.5 ConversionThe Conversion NFR organizes the requirements pertaining the conversion, when the new systemreplaces (a part of) an existing system .
The table below provides scenarios of Conversion NFRs
~
CN01 Performance of the complete system after implementation must stay thesame
CN02CN03
Version : 2 .0/ Status : Draft(06-June-2007) 147
Non-Functional Requirements Comprehensive Checklist40
ABN-AMRO
3.6 CorrectnessCorrectness refers to the assurance that input is correctly processed to produce consistent data setsaccording to the specifications . Correctness NFRs should not be confused with Data Integrity . In fact,the Correctness NFRs define the correctness of the process, while Data Integrity NFRs define thecorrectness of the data .
Scenarios of Correctness NFRs are provided in the table below :
4 ~ .
cool The application must support the transition between daylight savings timeand regular time without an incidents
C002 The input fields on screens should be checked by the use of appropriatevalues
C003 Acceptance environment must be completely configured by containingrepresentative data .
C004
Version : 2 .0/ Status: Draft (06-June-2007) 148
Non-Functional Requirements Comprehensive Checklistif
ABN-AMRO
3.7 Data IntegrityData Integrity NFRs define requirements related to the validity of data . Include requirements such asthe following :
• Specify the accuracy of data
• Provide methods of ensuring that data arrives at its destination as it was intended
• Currency of data
• Locality of updating data
• Two-factor user authentication is required for an integrity level of "Critical" (please contact
TRM for additional details regarding integrity levels) .
Scenarios of Data Integrity NFRs are provided in the table below :
. nr PriorityD101 After a disturbance the process at hand must end in the « . . .» limit so no
data integrity results from the disturbanceD102 All external communications between the system's data server and client
must be encrypted using ABN-AMRO standards .D103 Confidentiality of the data in the information system must be guarded every
«.,,» times a « . . .»D104D105
Version : 2.0/ Status: Draft(06-June-2007) 149
Non-Functional Requirements Comprehensive Checklist41
ABN-AMRO
3 .8 Data Retention
NFRs regarding Data Retention define to the length of time data needs to be retained . These includerequirements such as the following :
• Define whether the data is required to be available real time or can be stored in an archive
• Define what data needs to be retained
• How long does data need to be stored?
• What are the data purge criteria?
• Is the storage facility securely housed and protected from unauthorized access and
environmental hazards?
• How are the media resources securely locked up?
• What procedures are in place for handling sensitive information when no longer needed? This
includes paper, CD ROM, or other media kept under personal control .
Scenarios of Data Retention NFRs are provided in the table below :
Re f. ttr $Caer1air1+D PrlDR01 For performance reasons the application is allowed to keep data in the
session, but only when this data can be reconstructedDR02 The « . ..» data should be retained for « . . .» yearsDR03 Store less than « . . .» MB in session and for a time as short as possible
(cleanup when objects are no longer neededDR04 Data stored in a HTTP session must be externalizable regarding «. ..» or
serializable regarding « . . .»DR05 A HTTP session should not be used to store connections to external
resources (like database connectionsDR06 A HTTP session should not be used for data caching
Version : 2 .0/ Status : Draft(06-June-2007) 150
Non-Functional Requirements Comprehensive Checklist1P
ABN-AMRO
3.9 DegradationDegradation Requirements refer to the ease and quickness to resume the core information supply at alower level, after a malfunction that causes a lasting breakdown .
Scenarios of Degradation NFRs are provided in the table below :
Ref. ntDE01 In case of failure of one system component, the remaining components must
still be able to process « . . .»% of the peak loadDE02 In case of a failure of a complete computer site, the remaining site solution
must still be able to process at least « . ..»% of the peak loadDE03 The product shall continue to operate in local mode whenever it loses its link
to the central serverDE04 The product shall provide «. . .» minutes of emergence operation should it
become disconnected from the electricity sourceDE05 Unavailability of independent backend service will not result in service
de radation of other servicesDE06 Failure or degradation of a component in the « . . .» system application must
result in a error page that is understandable for « . . .» % of the users .
Version : 2 .0/ Status : Draft(06-June-2007) 151
Non-Functional Requirements Comprehensive Checklistit
ABN-AMRO
3.10 EconomyEconomy Requirements refer to the relationship between the performance level of the entireinformation supply (online and batch) and the total amount of resources used . Examples of EconomyNFRs are represented in the table below :
Scenarios of Economy NFRs are provided in the table below :
. owEC01 If the peak load of a transaction is expected to be more than « . . .»
transactions per hour: the average CPU usage per transaction must bedetermined
EC02 For transactions which use more than «. . .» milliseconds CPU pertransaction average, a strobe-report and an additional analysis must bemade
EC03 High performing . With limited bandwidth the midrange systems must respondwithin « . . .» seconds wall clock time / no CPU constraints . Content transferminimized (Compress output, generate efficient XML/HTML, browsercaching)
EC04 The system should claim as little as « . . .» % of the Wide Area NetworkBandwith
EC05 The system must be network aware by operating under low quality of serviceor b reducing the window size under congestion situations
EC06 The system has to provide a cost and efficiency ratio of «. . .» % by havingthe ability to run on an combination of the following platforms « . . .»
Version : 2 .0/ Status: Draft(06-June-2007) 152
Non-Functional Requirements Comprehensive Checklist
3.11 Hardware
. ABN-AMRO
This NFR specifies the (additional) hardware elements that are required to implement this systemapplication . Examples could be the addition of a new server, additional data storage or additionalmemory. The environment in which the software will operate has to be described, including thehardware platform, operating system and versions, and any other software components orapplications with which it must peacefully coexist . These NFRs would answer the following includedquestions :
• Are the users widely distributed geographically or located close to each other?
• How many time zones are they in?
• Where is the data generated and used?
• How far apart are these locations?
• Does the data from multiple locations need to be combined?
• When does the data need to get there?
• Is additional hardware needed to house development and/or test sites?
• Is additional hardware needed for Technical Recovery?
• Is hardware a supported standard within ABN AMRO?
• Is hardware an appliance (non-standard server)? If so, can the appliance utilize O/S lockdown
and vulnerability scan?
• Are systems being housed in ABN AMRO approved physical data centers?
Scenarios of Hardware NFRs are provided in the table below :
. nr * C!HA01 The size of the table spaces in the different environments is calculated with
the use of:3) the average number of rows per table,4) the physical row length ( in bytes) of the table,5) the use of freepage and pctfree and
4) percentage of compression. So these specifications must be known andsupplied .
HA02 When the size of the table space (including the expected growth within ayear) is above the «. . .» MB, it is obligated to specify a primary and asecondary quantity of « . ., .» MB
HA03 The system has to have the ability to provide 24/7 availability whenexpiration of a license occurs . For example, when a license for one or morecomponents expires this should not cause an outage making the applicationunavailable .
HA04 The system has to continue to provide 24 .7 availability when a new license isissues for one or more of the components
Version : 2 .0/ Status : Draft (06-June-2007) 153
Non-Functional Requirements Comprehensive Checklist
3.12 Installation
Does the software need to be installed on servers?Does the software need to be installed on workstations?Batch processing slotWill installation follow the standard ABN AMRO softwarecycle?Who will be responsible for the installation?
Installation NFRs are related to the installation of the software . These include requirements such asthe following :
.
qPABN-AMRO
process and change control life
Are there special packaging requirements for the system or application?
Scenarios of Installation NFRs are provided in the table below :
.t r 0IN01 The product shall be distributed as a ZIP fileIN02 The product should be able to be installed by an untrained user without
recourse to separately-printed instructionsIN03 The product shall be of a size that can be fitted onto « . . .» CD sIN04 Installation of components must be described and unambiguously describedIN05 The installation of components on the system must be free from user-
id/password/environment-variablesIN06 Installation of components must be automatedIN07 The installation must fit into the physical en technical boundaries of the
installation mediumIN08 The activation of the components is a separate function within the installationIN09 The changes to the existing systems will be installed using their regular
installation procedures
Version : 2 .0/ Status: Draft(06-June-2007) 154
Non-Functional Requirements Comprehensive Checklist1P
ABN-AMRO
3.13 Legal, Audit & ComplianceLegal, Audit and Compliance Requirements organize requirements imposed by other parties .These NFRs specify any requirements that are necessary to comply with local, state and federalregulations as a result of this High-Level Business Requirement . This includes requirements such asthe following :
• Does the system fall under the jurisdiction of any law?• Americans With Disabilities Act• Patriot Act• Reg E, Reg Z, etc .• Basel• Sarbanes Oxley Act• Check 21• MIFID• GLBA - Gramm-Leach Bliley Act• FFIEC (Federal Financial Institutions Examination Council) strong authentication guideline• Has software license agreement been registered to ABN AMRO?• Are there any current deviations known for this application?• For more details regarding ABN AMRO Compliancy regulations, see the following site :
htta ://aim . int.abnamro.com/index.html• For more details into the Compliancy rules for subsidiaries of the bank located in the
Netherlands, the VRNU (Van Regel Naar Uitzondering) initiative is a helpful initiative .
• For more details on North America Bank Regulatory Compliance see the following site :http ://cu rrency . na . abnam ro .com/ic/reca uiatorv/index . htm
This document will refer to the sources that are described above for an extensive overview of thedifferent Legal, Audit and Compliance NFRs . Scenarios of Legal, Audit and Compliance NFRs areprovided in the table below :
RK nrLE01 Norms and standards of « . ..» must be followed .LE02 Namin conventions for « . . .» components must be followed .LE03 For programming standards follow the instructions mentioned in «, . .» :
XMW07\DBMSIWCX for zOS\Standards\ XXX.docLE04 Application conforms to ABN AMRO naming conventions . Databases,
system files, . . .LE05 The system should have correct versions of infrastructural components
(conform AAB standardsLE06 The « . . .» application has to comply with the « . . .» firewall policies
regarding « . ..»
Version : 2 .0/ Status: Draft (06-June-2007) 155
Non-Functional Requirements Comprehensive ChecklistW
ABN-AMRO
3.14 MaintainabilityThe Maintainability Requirement refers to the necessary effort to make specified modifications .For the application to be build, there may be special requirements for maintainability . These includerequirements as the following :
• This product must be able to be maintained by its end-users• This product must be able to be maintained by support teams who are not the original support
teams .• The system must be able to modify and extend functionality• The system has to developed in reusable components (service components)• The system must be work at several places .
This has an effect on the way that the product is developed, and there may be additional requirementsfor documentation or training . This includes any special conditions that apply to the maintenance ofthis product such as the following :
. Irw PriorityMA01 Make use of easy to use and maintain style sheets .MA02 New MIS reports must be available within one working week of the date the
requirements are agreedMA03 A new alert code must be able to be added to the system overnightMA04 «. . .» will be responsible for system maintenance
Development of reusable business services (see identified services)Remark: sco in conform the architecture of the « . . .» application
MA05 Presentation layer can support different interface technologies (XML/XSLapproach used
MA06 «. . .» framework is used for controller layer .MA07 Creation of « . . .» specification is mandatoryMA08 All web applications must use the «. . .» Serviet to serve the dynamic
pages subclass of Struts controller ServietMA09 Static files from « . . .» are served by FileServingServlet (default
Webs here/WSAD file serving mechanism is disabledMA10 A ResourceServlet has to be used to serve XML resource files included in
document-functions in XML pagesMA11 An output trimming filter is used to remove empty lines . Guarantee that XML
processing instruction is at start of response bodMA12 Tag-libraries should be used in the following order of preference :
JSTL, Struts-EL, ABN-AMRO specific libraryMA13 Splitting of applications has to relieve the strains of impact on test capacity
new releases, stability of the entire system and manageability .MA14 Maintenance Agreements with third parties must be defined . This includes
the name of the parties, contact people, date and place of contract, duration,and way of continuation/revision, kind of service, service window, way ofcommunication, matching actions, quality checks, rates, way of charging,penalties, and links to relevant documents .
Version : 2.0/ Status : Draft (06-June-2007) 156
Non-Functional Requirements Comprehensive Checklist1P
ABN-AMRO
3.15 ManageabilityManageability refers to the necessary effort to operate and manage the information system . There aretwo types of Manageability NFRs : NFRs that cover a manageability function and NFRs that explainhow this manageability function is established . The central questions regarding the Manageability NFRare the following .
• What are the preconditions of the system so operators can manage the system?
Regarding the systems that support the manageability of the application to be developed, the followingremarks can be made .
• Topaz and Tivoli are applications that refer to the Manageability of systems that areconstructed for your BU .
• OTMA/MQ affinity : As a result of the use of OTMA / MQ in transaction-chain(s), thetransaction-chain acquires system affinity . This requires extra attention during testing .
Both applications of manageability are represented in the table below :
Fief, fit $ O $"MG01 The user must not be able to configure the systemMG02 Documentation which is needed for acceptance and support of the system is
presentMG03 Versionnumber of a component must be retrievableMG04 Testware must be saved for the next releases of the systemMG05 If all transaction used by the system are stopped the system must display a
error message within « . . .» secondsMG06 For « . . .» % of the users it must be possible to solve problems based on
the messa es provided b the system .MG07 If the application is delayed, but still operates within the accepted maximum
delay of«. ..» seconds, then it is very important that feedback about thisdelay is given to the customer within « . . .» seconds
MG08 The helpdesk must be able to give up to date status information, not olderthan « . . .»
MG09 The helpdesk must have insight in the how the information system works inroduction for<< . . .» % of the questions
MG10 The numbers of calls and incidents must be known b the hel deskEve registered user will have access to the hel site via the Internet .
MG11 Authorized personnel must be able to perform a «,, .» action from outsidethe ABN AMRO network
MG12 Workinstructions for the bridge of the « Symphony vendor» must bespecified
MG13 Monitoringo Standard logging connected to Tivolio End to end monitoring b Topaz (or other scripts .
MG14 All components must facilitate monitoring on functional and technical level .MG15 IS300 messages: Calling IS300 is only allowed for writing warning's, errors
and messages into the IS300 message-database for research afterwards .MG16 In production the runstats must be performed regularly . This must be
followed by a rebind of the plans involved, so the programs will use theaccess-paths based on statistical information .
MG17 The index-statistics must be updated «. . .times/ . . .»
Version : 2 .0/ Status : Draft(06-June-2007) 157
Non-Functional Requirements Comprehensive Checklistif
ABN-AMRO
3.16 PerformancePerformance NFRs cover a broad range of aspects . The Performance NFR, also known as the SpeedRequirement, refers to the response and processing times and throughput rates in online and batchinformation processing . Performance NFRs can relate to :
Users• Expected number of concurrent users• Number of total users of each profile (e .g . administrators, bankers, customers, groups, etc .)
Connections/Terminals• Number of active connections to the system• Number and type of terminals to be supported
Transactions• Number of transactions per interval and types of transactions, e .g. search query, update query
etc .• Transaction volumes - Are there significant spikes in volume each day, week, month, or
season?
Files/Size of Data• Total and simultaneously transferred number of files• Size of files and tables• Are there size or capacity constraints on the data to be processed by the system?• What is the amount and type of information to be handled?
Response Time/Throughput time• Are there any speed, throughput, or response time constraints on the system?• Response time - specify desired response time per transaction (e .g. time to retrieve a
requested page/screen, data or confirmation about end of process, etc .)
Scenarios of Performance NFRs are provided in the table below:
Ref: nr Scenario PniiPEOI It must be possible to finish a payment transaction within « . . .» seconds .PE02 Transfer within « . . .» secondsPE03 The response time for a single page must not exceed « . . .» seconds
excluding transportPE04 The response on the midrange systems (WebSphere) must not exceed
«. . .» secondsPE05 The cumulative response of the backend must not exceed «. . .» seconds .PE06 99% of the downloads start within « . . .» seconds ;
100% of the downloads starts within « . . .» seconds .PE07 The performance of a switch order must be at least as good as a regular
orderPE08 Performance entering orders having international options should equal
orders having domestic optionsPE09 Time to enter, send and perform electronic « . . .» should be less or the
same as a traditional « . . .»PE10 Starting and stopping of the environment must take less than « . ..»
minutes .PE11 Where technically possible the same data in the same session should not be
sent more then once : the application must perform maximum caching (takinginto account the requirement of the actuality of the data).
PE12 In case that the regular processing time of the required mainframe callsexceeds the «. . .» seconds processing time limit, the midrange platformshould, where functionally possible, make calls parallel .
PE13 The cumulative processing time must be measurable: waiting time of the«. . .» application (midrange) on the external mainframe systems .
Version : 2 .0/ Status: Draft (06-June-2007) 158
Non-Functional Requirements Comprehensive Checklistgo
ABN-AMRO
PE14 The number of concurrent users for the « . . .» multi-user application mustnot exceed « . ..»
PE15 Only for batch processes : The process must start at least at « . . .» andshould be finished after « . . .»
PE16 Only for batch processes : the lead-time of the process must not exceed«. . . »
Version : 2 .0/ Status: Draft (06-June-2007) 159
Non-Functional Requirements Comprehensive Checklist*I
ABN-AMRO
3.17 Portability
Portability Requirements specify attributes of software that relate to the ease of porting the software toother host machines and/or operating systems . This may include :
• Percentage of components with host-dependent code• Percentage of code that is host dependent• Use of a proven portable language• Use of a particular compiler or language subset• Use of a particular operating system
Scenarios of Portability NFRs are provided in the table below :
.1t1'Pool The product is expected to run under Windows «. . .» and UnixP002 The product is designed to run in offices, but version a product should also
be able to run in customer residences .P003 Reusable IMS transaction wrappers should be developed for the « . . .»
applicationP004P005
Version : 2 .0/ Status: Draft (06-June-2007) 160
Non-Functional Requirements Comprehensive Checklist1P
ABN-AMRO
3.18 RecoveryRecovery NFRs refer to the ease and assurance to restore the information supply after a malfunction .The backup and recovery section traditionally addresses two specific requirements :
• Error correction (e.g. inadvertent deletion of a necessary file or files) and
• Disaster recovery .
Scenarios of Recovery NFRs are provided in the table below :
Rteff nr g M~.RC01 Emergency procedures that are in effect in case of system failure must be
described, as well as the requisite actions, the departments and thedecision-makers involved. The conditions under which and exactly how onereverts to normal processing must also be clearly specifi2d .
RC02 Recovery Point Objective (RPO) - Describe the age of the data you want theability to restore in the event of a disaster . For example, if your RPO is«, . .»hours, you want to be able to restore systems back to the state theywere in, as of no longer than « . . .»hours ago . To achieve this, you need tobe making backups or other data copies at least every « . . .»hours . Anydata created or modified inside your recovery point objective will be eitherlost or must be recreated during a recovery . If your RPO is that no data islost, synchronous remote co solutions are your only choice .
RC03 Recovery Time Objective (RTO) - The Recovery Time Objective is the timeneeded to recover from a disaster or how long you can afford to be withoutyour systems .
RC04 If the system collapses completely there must be an emergency procedureRC05 For disaster recovery, the maximum failover time of the « . . .» application
must be less than « . . .» minutes
Version : 2 .0/ Status : Draft(06-June-2007) 161
Non-Functional Requirements Comprehensive Checklist
3.19 ReliabilityNFRs regarding Reliability can define:
ifABN-AMRO
• The extent to which the program performs with required precision
• The constraints on the run-time behavior of the system
• Failure rate - how often does the system fail to deliver the service expected by end-users?
Generally, NFRs can state in words what the reliability of the system should be . These requirementsare reflected in de ands from the business. Secondly, there are Reliability NFRs that are puretechnical and consider the reliability of the system in measurable terms . These requirements definehow the aforementioned reliability type is realized .
Scenarios of Reliability NFRs are provided in the table below:
4 nr Seenaf{taRE01 Data received from the « . . .» system must be stored in a« . . .» wayRE02 Distribution-tools and procedures must be in place during « . . .»'/o of the
timeRE03 Failure of a system must not lead to loss of user transactions or session dataRE04 Existing components must not involuntary change due to the new
implementationRE05 Batch processing must be within SLA-requirementsRE06 Relations between entities are still present after update by external
processes MI delivery/Bankmail delivery etc.RE07 All entities, which belong together, must be cleaned together so no
involuntary changes are met .RE08 Environment has a strictly divided data and presentation layerRE09 The system should contain independent startable & stoppable web
applicationsWithout functional problems or service degradation
RE10 The system has to have the ability to be available «. . .» during daytimeregardless of firewall and network appliance topology changes
RE11 Exceptions DB2: For transactions which are traced by one of the DB2exception traces EXO%, a DB2trace and an additional analysis must bemade .
RE12 (dead)lock / time-out: At most « . . .»"/o of the transactions are allowed tohave a dead lock / time-out (=U0777 during the loadtest
RE13 User or System abend : At most « . . .»% of the transactions are allowed tohave a User or System abend other than dead lock / time-out (=U0777) .
RE14 «. . .»%, of the screens should contain actual information during prime timeRE15 «. . .»% of the screen should contain actual information outside prime time
Version : 2 .0/ Status: Draft (06-June-2007) 162
Non-Functional Requirements Comprehensive ChecklistIf
ABN-AMRO
3.20 ResilienceThe Resilience Requirement refers to the ease and assurance the information is recovering itself aftera malfunction .
Scenarios of Resilience NFRs are provided in the table below :
. fW Scenario .RS01 Backup from the system must be in placeRS02 The proper functioning of the system in one computer site must not depend
on, or affect, the functioning of the system at the other computer siteRS03 The system must be able to proceed its processes after a disturbance .RSO4 Backup from the system must not disturb performance of the systemRS05 If the « . . .» application is delayed, but still operates within « . . .» seconds
delay, then feedback about this delay should be given to the customer within«. . .» seconds
RS06 The process at hand at the moment of the disturbance must complete itsprocess
RS07 The « . . .» application provided automatic restart and resend of partialand/or failed transfers .
Version: 2 .0/ Status : Draft (06-June-2007) 163
Non-Functional Requirements Comprehensive Checklist1P
ABN-AMRO
3.21 ScalabilityThis NFR specifies the expected increases in size that the product must be able to handle. Asbusiness grows (or is expected to grow) our software products must increase their capacities to copewith the new volumes. This NFR states how the system should continue to perform over time aschanges in volume or system size occur in order to meet a user need, such as growth or datamigration. Also specify volumes of users and data the system will support ; this can be expressed as aprofile over time (i .e . projected growth for 6 month, 1 year and 3 year periods) .
Scalability comes in two flavors : horizontal and vertical :
• Horizontal scalability is achieved when the same application can run on multiple hardwareplatforms simultaneously . This is no trivial task and typically requires special features in theapplication's software as well as its configuration .
• Vertical scalability is achieved when the application can be broken up into pieces that can bespread across the various hardware platforms in an environment . Typically one of the layers ina multi-layered application is installed on a piece of hardware . This can be trivial when theapplication's layers are already communicating in a network transparent manner (RMI, JDBC,TCP/IP, etc) .
Scenarios of Scalability NFRs are provided in the table below :
Ref. nr Scenario pr1oftSC01 The system must be scalable based on hardware expansion alone (no code
changes neededSC02 The application should be capable of processing the existing « . . .»
customers. This number is expected to grow to « . . .» within « . . .» years .The system should be capable of processing this increase in volume .
SC03 The application should be able to process «. . .» transactions an hour within«. . .» years of its launch
Version : 2 .0/ Status: Draft(06-June-2007) 164
Non-Functional Requirements Comprehensive Checklistif
ABN-AMRO
3.22 SecuritySecurity requirements are included in a system to ensure that unauthorized access to the system andits data is not allowed, and to ensure the integrity of the system from accidental or malicious damage .Security NFRs are a collection of many different types. This includes requirements such as thefollowing :
• Any requirements regarding security or privacy issues surrounding the use of high-levelbusiness requirements
• Any requirements regarding protection of the data used or created by this requirement(examples: encryption, access control to data)
• Identity authentication requirements
• External policies or regulations containing security issues that affect the product and include a
link to those policies or regulations
• Security or privacy certifications that must be satisfied
• Local or product specific regulation requirements .
• Processes and procedures for segregation of duties .
• Processes and procedures for the following access control requirements :
• User notification
• Identification
• User authentication
• System/application authentication
• Prevention of password guessing
• Authorization
• Alerting
• Logging
• Are procedures available for acceptance testing and change management?
• Is there any data transferred over the Internet?
• Are there any logs or reports to monitor system access?
• Have the Third Parties, who are responsible for hosting or managing ABN AMRO data, beenappropriately certified?
• How often are files, programs, database backed up? Who is responsible?
• Are there recovery plans and backed up information available at both on-site and off-sitelocation?
• The AIM intranet also provides a thorough collection of Security NFRs :htta ://aim .int .abnamro .com/i ndex .html
Version : 2.0/ Status: Draft (06-June-2007) 165
Non-Functional Requirements Comprehensive Checklist1P
ABN-AMRO
Besides, many Security NFRs are represented by CIA (Confidentiality, Integrity and Availability)ratings . A Rating of 111 means that all the activities are critical .
Scenarios of Security NFRs are provided in the table below:
. *1 _SE01 The access permissions for system data may only be changed by the
security data administrator .SE02 Application-, system-, database- and log-files should be stored physically
se aratedSE03 All system data must be backed up every « . . .» hours and the backup
copies stored in a secure location that is not in the same building as thesystem .
SE04 Only « . . .» can see the personnel records of their staff.SE05 The servers must be scheduled for vulnerability scan and lockdown prior to
roductionSE06 Authority for users for access to the system must be arranged easilySE07 The number of ent attempts must be monitoredSE08 After blocking of a user password it must be possible to unblock the
passwordSE09 Changes in security must be tuned with the security departmentSE10 The system must not be sensitive for internal or external fraudSE11 Security in the system must work conform the «. . .» specificationSE12 Changes within the data of the system must be followed through the system .
In other words: there must be an audit trailSE13 Application will use « . . .» security on the level of URLsSE14 It should be possible to apply security on EJB method levelSE15 Security cookie will maintain the security contextSE16 Do not publish risk full information within HTML codeSE17 Do not publish risk full information within HTTP headers or cookiesSE18 If an application does not have to use a HTTP session, it must not create
oneSE19 Application is not allowed to create HTTP session when user is not identifiedSE20 The application may not use cookies . (only infrastructural cookies allowedSE21 Test roles must not appear at all in production . This must be monitored by
the owner (AAB/ MCBS/ Security), who stipulates the norms of theSBT/MSEC set-up for the production environment
SE22 The authorities of the user who can make changes to the security rules mustbe restricted exclusively to those actions . Such a user may thus not haveany authorities to the components and/or functions to which he/she grantsother users authorization . ( This measure prevents security incidents andcan mean that the number of employees for resolving problems can be keptlow
SE23 In case of non-authorized access to parts of applications that are designatedas Critical due to susceptibility to Privacy and Fraud, (see the guidelines inthe Manual Security) such a failed attempt to log in must be logged in the logfile described in the Operations Documentation .
SE24 All resources belonging to an application that must be shielded must bedescribed . The corresponding roles and authorities must also be specified(not only the user world, but also for the operations and management world) .The resource description must consist of : the 'common name' ; the name bywhich the resource is known in the run time environment ; a brief descriptionof the contents; the reason for shielding .
Version : 2 .0/ Status : Draft (06-June-2007) 166
Non-Functional Requirements Comprehensive Checklistif
ABN-AMRO
SE25 Anonymous user IDs are not allowed . Task user IDs are obligatory for localapplications . A task user ID is needed per environment . This is also the casefor certain mainframe Task user IDs. (DB2, OPC
Version : 2.0/ Status : Draft(06-June-2007) 167
Non-Functional Requirements Comprehensive Checklistgo
ABN-AMRO
3.23 Software Dependency
This NFR specifies the software applications that are required to implement the system application .This includes requirements such as the following :
• Database software, e .g. Oracle, Mercator• Operating system software, e .g. Sun OS, Microsoft Operating Systems, z/OS, AIX, Redhat
Operating systems, Solaris, HP/UX, AS400, Safari 1 .0, Mozilla Firefox• Tools, e.g . Rational Application Developer, Microsoft Visual Studio, Visio• Application software, e .g. WebSphere Application Server, Business Objects• Testing tools, e .g. Mercury Loadrunner• ODBC/JDBC driver technology• Do additional/new environments need to be built for development or testing?• Do additional/new environments need to be built for Technical Recovery?• Will the application implemented require security tools for protection (SFTP, encryption
storage, Siteminder)?• What version control tools used to maintain integrity of application code?
Scenarios of Software Dependency NFRs are provided in the table below :
Rott nr o Prior iSD01 The « . . .» application has to be available on all preferred platforms (i .e .
«. . .» in BU «. ..»SD02 The « . . .» application has to be available on all non-preferred platforms
i .e. « . . .» in BU « . . .»SD03 The « . . .» application is available on all desktop platforms in BU « . . .»SD04 The system has to have an ability to integrate with supported functions of
«. . .» compliant application serversSD05 The system has to provide a« . . .» driver technology to enable loose
coupling with the « . . .» databaseSD06 The system has to connect with «SWIFT/Reuters/ Inter a»
Version : 2 .0/ Status : Draft (06-June-2007) 168
Non-Functional Requirements Comprehensive Checklist
3.24 Software Interface
IfABN-AMRO
Software Interface requirements describe the connections between this product and other specificsoftware components (name and version) . User Interface Requirements relate to interfaces internal tothe system, whereas Software Interface Requirements relate to interfaces external to the system .Include requirements such as the following :
• Connections to databases
• Connections to operating systems
• Connections to tools
• Connections to libraries
• Connections to integrated commercial components
• Identify the data items or messages coming into the system and going out and describe thepurpose of each
• Describe the services needed and the nature of communications
• Refer to documents that describe detailed application programming interface protocols andinclude links to those documents .
• Identify data that will be shared across software components . If the data sharing mechanismmust be implemented in a specific way (for example, use of a global data area in amultitasking operating system), specify this as an implementation constraint in the constraintssection for this High-Level Business Requirement
• Is the system using/connected to any outside software or external database? Includeinformation about the interface and a source where the exact specification can be found, andinclude a link to any documentation .
• If the system is connected directly to some program, include the exact version of that programhere .
Scenarios of Software Interface NFRs are provided in the table below :
ti0f. 0S101 The new version of the spreadsheet must be able to access data from the previous 2
versions .S102 We must be able to interface with an htmi browser .S103 Our product must interface with the « . . .» Mainframe applications .SI04 Business application « . . .» has to be encapsulated b the « . . .» interfaceS105 Business application Interface has always to be implemented as «,,,»S106 Business service « . ..» has to be encapsulated b an interfaceS107 Business service interface has always to be implemented as « ..,»S108 The « . . .» application supports interfaces with the System Management Standard
Version : 2 .0/ Status: Draft (06-June-2007) 169
Non-Functional Requirements Comprehensive Checklistif
ABN-AMRO
3.25 SuitabilityNFRs regarding the Suitability of the system refer to the presence and the appropriateness offunctions within the existing or implied procedures .
• Many Suitability NFRs refer to the "niceness" to use . The most direct methods to measure thissatisfaction is to survey actual users and record the proportions of users who like to work withthe product.
Scenarios of Suitability NFRs are provided in the table below:
o nr '- sr6ina,0SU01 Creation of output-data and presentation should be executed in separate
rocesses
7SU02 All the tasks that are present in the process, must also be entailed in theapplication
Version : 2.0/ Status : Draft(06-June-2007) 170
Non-Functional Requirements Comprehensive Checklist0
ABN-AMRO
3.26 TestabilityTestability Requirements refer to the necessary effort to validate the modified information system .
Scenarios of Testability NFRs are provided in the table below :
. rar S PriTE01 The solution should be decomposed into separate deployable and testable
units .TE02 Business layer components and application layer components will be
separately testable .TE03 Representative loadtest : If the peak load of a transaction is expected to be
more than « . . .» transactions per hour: a load test must offer arepresentative load of « . . .»'/o of the peak load expected on the productionsystem including the total infrastructure, during « . . .» minutes minimally .
TB04 A pilot environment must be made available to perform productionverification tests with « . . .» end users
TB05 The system has to support load balancing between multiple distributed datacenters
Version : 2 .0/ Status : Draft(06-June-2007) 171
Non-Functional Requirements Comprehensive Checklist9
ABN-AMRO
3.27 TimelinessThe Timeliness NFR defines the assurance that information is available for other processes within thespecified time span .Two types of Timeliness NFRs: NFRs that define
• What the timeliness NFRs supposes to be and
• The underlying performance to reach that the timeliness is realized .
Scenarios of Timeliness NFRs are provided in the table below :
. nW P"9TI01 Performance of new on-line components must be within the SLA limitT102 Using the infrastructure with new components that operate differently, must
not result in disturbancesT103 Use on non-own system components must not lead to degradation of
performanceT104 The Basel I I« or other » monthly data processing shall deliver the
calculated templates on the 7th business da of the month or earlierT105 The system delivery of the distribution layer will be delayed by a maximum of
« . .,» hours in case problems occurT106 The data have to become available in ultimately « . . .» month after the
forthcoming month has been endedT107 Response times of screens must be within the time-out valuesT108 Performance of the complete system after total implementation of the « . . .»
application must sta the sameBefore implementation all know errors must be documented
Version : 2 .0/ Status: Draft (06-June-2007) 172
Non-Functional Requirements Comprehensive ChecklistIP
ABN-AMRO
3.28 TransferTransfer NFRs refer to the ease and quickness to continue the core information supply in anotherlocation, after a malfunction that causes a lasting breakdown . The Transfer NFR, that finds it basis inBUNL, has similarities with the Data Migration NFR at BUNA covering the requirements surroundingthe migration of data from one system to another .
These include requirements such as the following :
.tW $ PTR01 The data must be migrated from the « . . .» systemTR02 The volume of the data that have to be transferred is « . . .»TR03 The migration involves the following interfaces: « . . .»TR04 The data is being migrated to the external entity « . . .»
Version : 2 .0/ Status : Draft (06-June-2007) 173
Non-Functional Requirements Comprehensive ChecklistIP
ABN-AMRO
3.29 UsabilityNFRs regarding the Usability define the adjustment of the information system to the culture and theautomation degree of the organization it is meant for. This means that the following requirements haveto be in the system :
• Specific requirements for the use of the system in local areas• Specific requirements to meet local laws and regulations• Specific requirements for the global use of the application• Handling Requirements denote the error rate of the end-users of the system . This could be
measured in terms of the errors made when working at normal speed .
Scenarios of Usability NFRs are provided in the table below :
>rtrUS01 There has to be specific requirements for person with disabilities, like « . . .»US02 There should be used large characters for displayUS03 The system should enhance multi-lingual useUSO4 The standard language of the front end of the system is DutchUS05 Error messages and system messages must be usable for « . . .»'/o of the
users .
Version : 2.0/ Status: Draft(06-June-2007) 174
Non-Functional Requirements Comprehensive Checklist40
ABN-AMRO
3.30 User-friendlinessUser-friendliness NFRs refer to the ease for the user to learn to associate with the information systemand the ease for experienced users to use the information system . User-friendliness NFRs could referto :
• Specific requirements for assistive technologies• Requirements for use of auditory signals
User-friendliness NFRs are NFRs that originate from business demands . For this reason, thedescription of this NFR type often reflects a desire by using words like clear, clarifying and usable,which makes it difficult to make the NFRs SMART .
Scenarios of User-friendliness NFRs are provided in the table below :
Fi+efK rN' 3cwtwi+aUF01 The hel facilities must be for « . . .» % of the users clear and usableUF02 There has to be a single sign-on for using the applicationUF03 For « . . .» of the users, there have to be clear data directories (dictionaries)
that rovide definitions of data itemsUF04 The menu-structure must be clear for « . . .» % of the usersUF05 The screens must be clear and clarifying for « . . .» % of the usersUF06 Overviews generated by the system must be clear and clarifying for « . . .» %
of the usersUF07 The styling f content should be based on « . ..»
Learning Requirements, which denote the time needed to learn the facilities of the system and canbe considered as being a part of User-friendliness Requirements . This could be measured interms of speed of learning, for example, hours of training required before independent use ispossible.
Version : 2 .0/ Status : Draft (06-June-2007) 175
Non-Functional Requirements Comprehensive Checklist
3.31 User Interface
IfABN-AMRO
User-interface requirements describe the logical characteristics of each interface between thesoftware and the users, and define the software components for which a user interface is needed .User Interface Requirements relate to interfaces internal to the system, whereas Software InterfaceRequirements relate to interfaces external to the system .)These do not include design specifications . The details and the final user interface design will bedetermined during the Design phase, and will be documented in a separate Functional Designspecification documents .
• Include requirements such as the following :
• Sample screen images
• Any Graphical User interface (GUI) standards or product family style guides that should be
followed
• Screen layout constraints
• Standard buttons and functions (e .g ., Help) that will appear on every screen
• Keyboard shortcuts
• Error message display standards
• How should the system respond to input errors?
• How should the system respond to extreme conditions?
• Does user get prompted for a user ID during system login?
• How are users granted access and profile (by department, business function, transaction,
security level)?
• Is there a profile maintenance procedure?
• Will the system block the user ID after four failed login attempts?
• Does the user ID conform to ABN AMRO password policies?
• Are there command line interface requirements, i .e. does the user need to invoke anything
from the command line?
Scenarios of User-Interface NFRs are provided in the table below :
. R1rU101 The system should use a GUI (Graphical User Interface) for system
administration
Version : 2 .0/ Status : Draft(06-June-2007) 176
Non-Functional Requirements Comprehensive Checklist ∎ ABN-AMRO
4. Glossary
This section will serve as a glossary for the terms that have been used in this document .
AIM ABN AMRO Instruction ManualAPI An application programming interface (API) is a source code interface that a
computer system or program library provides to support requests for services tobe made of it b a computer program
Batch processing is the execution of a series of programs ("jobs") on a computer without humaninteraction, when possible .
BU Business UnitCIA Security rating in respect of Confidentiality, Integrity and Availability .Cookies cookies, sometimes known as web cookies or HTTP cookies, are parcels of text
sent by a server to a web browser and then sent back unchanged by thebrowser each time it accesses that server .
CPU A Central Processing Unit or sometimes simply processor, is the component ina digital computer that interprets computer program instructions and processesdata
CST Central Standard Time (North AmericaData caching Data caching is used by the CPU of a computer to reduce the average time to
access memory .Data center A facility used to house mission critical computer systems and associated
componentsDB2 IBM's line of Relational Database Management Systems software productsDBMS A database management system (DBMS) is computer software designed for the
purpose of managing databases . .EJB Enterprise Java Bean (EJB) is a managed, server-sided component for modular
construction of enterprise applicationsFTP FTP or File Transfer Protocol is used to transfer data from one computer to
another over the Internet, or through a network .GUI A graphical user interface (GUI) is a type of user interface which allows people
to interact with a computer and computer-controlled devices which employgraphical icons, visual indicators or special graphical elements along with textlabels or text navigation to represent the information and actions available to auser
Health check IT health checks identify vulnerabilities in IT systems and networks which maycompromise the confidentiality, integrity or availability of information held on thatIT system
HTML HTML (Hypertext Markup Language) is the predominant markup language forthe creation of web pages
HTTP Hypertext Transfer Protocol (HTTP) is a communications protocol used totransfer or convey information on the World Wide Web
JDBC JDBC is an API for the Java programming language that defines how a clientmay access a database. It provides methods for querying and updating data in adatabase. JDBC is oriented towards relational databases .
JSP JavaServer Pages (JSP) is a Java technology that allows software developersto dynamically generate HTML, XML or other types of documents in response toa Web client request .
JSTL The JavaServer Pages Standard Tag Library (JSTL) encapsulates as simpletags the core functionality common to man Web applications .
JVM A Java Virtual Machine (JVM) is a set of computer software programs and datastructures which implements a specific virtual machine model
LAN A local area network is a computer network covering a small geographic area,like a home, office, or group of buildings .
Load balancing Load balancing is a technique (performed by load balancers) to spread workbetween man computers, processes, hard disks or other resources in order to
Version: 2.0/ Status : Draft (06-June-2007) 177
Non-Functional Requirements Comprehensive ChecklistIV
ABN-AMRO
get o timal resource utilization and decrease computing time .Load test Load testing is the process of creating demand on a system or device and
measuring its response . It is a blanket term that is used in many different waysacross the professional software testing community
Maintenance The maintenance window is the period between 23 .00 hour Saturday eveningWindow and 7.00 hour the next Sunday morningMCBS Multi Channel Business SolutionsMidrange server/ Midrange servers refer to computers that are more powerful and capable thansystem personal computers but less powerful and capable than mainframe computers .MIPS Million of Instructions Per MinuteMIS Management Information Systems (MIS) is a general name for the academic
discipline covering the application of people, technologies, and procedures -collectively called the information system - to solve business problems
MSEC Multicast Security's purpose is to standardize protocols for securing groupcommunication over internets, and in particular over the global Internet .
Non-Functional Requirements that include standards, regulations, and contracts to which theRequirement product must conform. These can be descriptions of external interfaces,
performance requirements, design and implementation constraints and qualityattributes (Wiegers, 1999)
ODBC Open Database Connectivity (ODBC) provides a standard software API methodfor using database management systems (DBMS) .
OLTP Online Transaction Processing : is a class of programs that facilitate andmanage transaction-oriented applications, typically for data entry and retrievaltransaction processing
OTMA/MQ OTMA/MQ is transaction-based connectionless client/server protocol .Overnight See secondary service windowPeak Load The highest amount of users who want use the system parallel of each otherPrimary Service The primary service window is the period between 7 .00 hour in the morning andWindow 23.00 hour the same daPrimetime See primary service windowResponse time response time is the time a system or functional unit takes to react to a given
inputRPO The Recovery Point Objective (RPO) describes a point in time to which data
must be restored in order to be acceptable to the owner(s) of the processessupported b that data
RTO The recovery time objective (RTO) is the boundary of time and service levelwithin which a business process must be accomplished to avoid unacceptableconsequences associated with a break in Continuity
SBT Systeem Basis ToegangsregelingSecondary The secondary service window is the period between 23 .00 hours in the eveningService Window and 7.00 hour in the next morning .Serviet A Serviet is an object that receives a request and generates a response based
on that request. The basic serviet package defines Java objects to representserviet requests and responses, as well as objects to reflect the serviet'sconfiguration parameters and execution environment .
Siteminder SiteMinder provides an enterprise-scale security infrastructure that enables toprovide secure access to Web applications and Web sites for employees, andcustomers .
SFTP Simple File Transfer Protocol (SFTP) is an (unsecured) file transfer protocol witha level of complexity intermediate between TFTP and FTP
SLA Service Level Agreement (SLA) is that part of a service contract where the levelof service is formally defined .
SMART Specific Measurable Achievable Relevant Time framedTFTP Trivial File Transfer Protocol (TFTP) is a very simple file transfer protocol, with
the functionality of a very basic form of FTPTime-out value Time-out value is the number of seconds that the report server waits for a
response from the databaseTopaz Monitoring tool to measure the performance
Version : 2 .0/ Status : Draft(06-June-2007) 178
Non-Functional Requirements Comprehensive Checklist41
ABN-AMRO
Tivoli Tivoli Software is a systems management brandURL Uniform Resource Locator (URL) is a technical, Web-related term used to define
the location on the web .WebS here Software brand for midrange server applicationsWide Area Wide Area Network (WAN) is a computer network that covers a broad area (i .e .,Network any network whose communications links cross metropolitan, regional, or
national boundaries .
Version : 2 .0/ Status : Draft(06-June-2007) 179
Non-Functional Requirements Comprehensive Checklist
5. Clarification
1PABN-AMRO
This document won't aim to prescribe one singular way BUs should handle NFRs . In fact, at thismoment every BU has its own set of high-level NFRs and its own way of documenting these . In fact,for many high-level NFRs only a thin line exists between other high-level NFRs, like between the User-friendliness and Usability NFR .
For this reason, this document wi!l serve as a clarification to list a!l the different types of NFRs that areused throughout the ABN AMRO bank . By listing these NFRs in the table presented in section 2, thisdocument aims to provide an exhaustive set of NFR used in the bank .
Further, this document has provided for each high-level NFR scenarios that served a genericapplicability by avoiding of being too superficial . By this way BUs can add their own context to thisgeneric NFR and make them suit to their situation .
In fact, before establishing one way for setting requirements in a!l the BUs of ABN AMRO, BUs shouldbe familiar with its ways for setting requirements . Hopefully this document contributes to this mutualcommon understanding!
Version : 2 .0/ Status : Draft(06-June-2007) 180
Non-Functional Requirements Comprehensive ChecklistIP
ABN-AMRO
6. Credentials
As final remark and in line with section 1 .2, this document will end with thanking BUs for its extremelyhelpful contribution . Due to their work, this document could in fact be established .
We would like to thank BUNL for their extensive way of describing the different NFR types, and theirextensive way of documenting NFRs .
We would like to thank BUNA for their helpful Requirements template . Especially its logical structureand its exhaustive way for enabling NFR setting provided much clarity how NFR setting takes place .Finally, we want to thank BUTB by the large amount of documents that we gathered that have result inan extensive insight in NFR setting .
Version : 2 .0/ Status: Draft (06-June-2007) 181
