Managing Natural Language Programme Requirements for Basel II

"The use of natural language to prescribe complex, dynamic systems has at least three severe problems: ambiguity, inaccuracy and inconsistency. Many words and phrases have dual meanings which can be altered by the context in which they are used." NASA-Software Assurance Technology Center

INTRODUCTION

NOTE: the opinions of the author are his own and do not represent the views of RBC.

This section captures some of the best practices used in managing the Basel II requirements in 2005 for the regulatory programme executed at Royal Bank of Canada (RBC) over a three year period. These practices are documented here as in my opinion some quite unique work was done to manage the requirements phase of this programme. There were some ups and downs experienced as is normal for large programmes, but the end result was an on-time regulatory programme delivery. The lessons learned here may be useful for readers using plan-based approaches for their programmes.

Basel was an international capital framework, called the “International Convergence of Capital Measurement and Capital Standards: a Revised Framework”, more commonly known as “Basel II”. It altered the way institutions manage and measure their risk exposure. The strategic intent of international regulators was to ensure the safety and soundness of the global financial system and to promote improved risk management practices. Compliance is mandatory for internationally active institutions in participating jurisdictions.

Because the Basel requirements were still being defined (in the form of compliance paragraphs), the bank's executives decided to wait until the requirements were firmed up before starting the project. As a result, the project started late but the deadline constraint imposed by the regulator (OSFI) had not changed. Delivering all requirements to meet Basel's 1040 paragraphs successfully, given the time constraints, was going to be challenging.

Simply stated, the Basel requirements relate to the bank's risk capital adequacy. How much liquidity must the bank maintain to cover possible systemic risks. To determine that, the bank must understand it's risk exposure (e.g. potential bad loans, impact of changing interest rates, other defaults, FX currency fluctuations, etc.). The more capital that must be set aside to cover a risk, that's capital that's not being productively used to generate profits. Therefore, banks need to minimize their portfolio risks to minimize the capital required to cover such risks. The amount is usually a small percentage of their total assets under management (AUM). The lower the percentage the better! However, it's not a figure that is publicly released.

Stress tests are run on a quarterly basis to determine the bank's potential exposure to internal and external risks. For example, what happens if interest rates increased from 5% to 9%, what percentage of the bank's loan holders will default? If this happens, what is the financial loss (exposure) to the bank. Will the bank have sufficient capital set aside to cover these bad loans? It's a complex question, due to the number, amount and variety of loans that banks make to public and corporate clients. This is why risk management systems were enhanced to capture additional firm data to perform this complex calculus. I'm not sure if the results of stress tests are shared with the financial regulators, I suspect they are needed to maintain the bank's annual Basel compliance.

Basel II Paragraphs

The Basel II regulatory requirements were stated as Paragraphs. The paragraphs were the things that a bank must do to be Basel compliant; for example running quarterly stress tests. The Gaps are the things that the bank is not yet doing but is required to do to meet the regulation. This is why it's called a Gap. The business requirements are created to describe a solution that will close the gap. Once the requirement documents are complete, they are passed to the technical teams to implement the solution. Perhaps, it's the acquisition of a new risk management system. It could also be an enhancement to an internal system (build versus buy). In the end, evidence needs to be provided to the regulator that any gaps have been closed by technical solutions or process changes. The process is illustrated below:

Basel Paragraphs to Gaps

PROGRAMME MANAGEMENT

As was customary for large banks, whenever a large programme was initiated it was often managed by a consultancy familiar with large programme management. They brought experience and staff in managing large projects. This could be Cap Gemini, CAPCO, Deloitte or more often IBM Global Services. For Basel, IBM was brought in for overall programme management. The IBM programme head was a former CIBC VP (one of their youngest at the time), who recently joined IBM. He was a great leader and well matched for the opportunity ahead. Once the Basel programme concluded, he joined RBC as a full-time VP.

As data complexity grew, eventually another consultancy was brought in to manage the data aspects of the programme.

THE REQUIREMENTS AND DOCUMENTATION MANAGEMENT TEAM (simply RMT)

Due to the size of the programme there was a need to have a dedicated team looking after the requirements gathering process and supporting the Business Analysts gathering the requirements. IBM Global Services was brought in to setup the initial programme framework. IBM installed RequisitePro (ReqPro) and adapted the business requirements document (BRD) from the project office to meet the needs of the Basel programme.

When I took over the RMT there was one full time RBC employee and one IBM contractor. The IBM contractor's role was the initial setup of the requirements process. Once that was completed, he left for other IBM engagements. The RBC employee, decided he was going to retire and left shortly after the contractor.

I hired two RBC employees and two contractors to run RMT for the duration of the programme. The RMT team was aligned with the technology area, reporting to a VP (David S.); one of the nicest and approachable VPs I had the pleasure of reporting to. It took me a while to find qualified candidates. My VP was concerned that hiring was slow, but I felt that we needed people with the necessary software development familiarity, internal company people network, experience and attitude for an effective team. We ended up with a great team; just in time for applying our skills to the programme.

The role of RMT was to:

Provide documentation standards.
Programme documentation guidance to Project Managers (PMs) and Business Analysts (BAs) on the requirements phase.
Bridge gaps between BAs and programme management.
Govern requirements repositories.
Mentor Business Analysts on requirements writing and process.
Mediate issues between analysts and programme reps.
Facilitate requirements reviews and quality scoring.
Manage controlled access to specifications.
Document cases where exceptions have been made to requirements processes.
Provide guidance on requirements development in natural language.
Provide metrics for the leadership team on the number requirements in system, completed, tested, orphans, etc.
On-going support to PMs and BAs through weekly information and training sessions.

As the RMT Manager, I was part of the programme senior leadership team (SLT) and had the privilege of close working cooperation with the senior programme leaders.

BUILDING QUALITY REQUIREMENTS

To build any product or service, the client's requirements must be clearly stated so that the final product meets the client's expectations. Requirements are the essence of any project; without clear requirements, project outcomes are uncertain. Specifying requirements has been a challenge for most firms. Various combinations of natural language Business Requirements Documents (BRDs) to use cases have been used to capture requirements. To this day, good requirements specifications remains a challenge for most firms.

For many years firms have relied on Natural Language Requirements (NL) specifications. This project was no exception.

There were 15 projects, each with multiple workstreams, required to close the Basel gaps. Due to the number of projects and the interdependencies among projects, a way to best manage the requirements and the documentation was needed. The requirements management tool selected by IBM was Rational's RequisitePro. I was familiar with other requirements tools, such as DOORS, from exploring these at General Electric (GE) when managing a software development team. DOORS was widely used by some GE aerospace clients and was the gold standard for such tools at the time. DOORS, is now part of the IBM application portfolio, similar to the acquisition of Rational products by IBM at the time.

For as-is and to-be diagrams, these were created with IBM's Rational Rose. The logic being that some of these would be common to multiple projects and therefore would be easier to manage them in a separate repository rather than in each individual business specification. As well, Rose's strength is the creation and maintenance of process diagrams. Any change to these diagrams would mean that multiple business specification documents would have to change, versus linking the business document to the individual Rose diagram repository.

I had a chance meeting with my RMT equivalent at CIBC. I understood they were also using RequisitePro but their approach to managing requirements to paragraphs was very different. Due to confidentiality concerns neither of us gave too much information on our bank's requirements approach on Basel.

Items published into RequisitePro:

Requirements: functional (parents and children), non-functional, audit, security and data
Assumtions
Business Rules

An important aspect of the programme was to demonstrate to regulators that each Basel paragraph (regulatory requirement) was linked to a gap and one or more business requirements. A gap meant that the bank was not meeting one of the Basel paragraphs (a regulatory requirement). Projects were then initiated to close the gap and satisfy the Basel requirement. Business specifications were then linked to the gap to demonstrate that the bank had an action plan and specifications for closing the gap.

The traceability chain of paragraphs to gaps to requirements to test results, etc. was required to ensure no regulatory requirements were orphaned. The traceability reports were evidence to the regulators that the bank addressed every regulatory requirement. On a quarterly basis, a report was sent to the regulator to show progress on the requirements coverage.

It was the responsibility of the BAs to establish the requirements traceability using RequisitePro.

Establishing traceability using RequisitePro:

Soft tag requirements within the Business Specification Document.
Publish requirements to RequisitePro.
Trace requirements as per traceability model.
Requirements are linked into gaps.
Assumptions and Business rules are traced to requirements.
Child requirements are traced to parent requirements.
Link the to-be process models to requirements.
Requirements that did not trace directly to a BASEL gap were traced to the project anchor gap.
Non-functional requirements were not traced.

Weak Phrases

Weak phrases are the bane of writing NL requirements. These are clauses that are apt to cause uncertainty and leave room for multiple interpretations. Use of phrases such as "adequate" and "as appropriate" indicate that what is required is either defined elsewhere or worst, the requirement is open to subjective interpretation. Phrases such as "but not limited to" and "as a minimum" provide the basis for expanding requirements that have been identified or adding future requirements.

Examples of weak phrases:

The XYZ system will have the same capability of the QSW System.
The XYZ system will effectively prevent fraud. ISSUE: "effectively" is spurious, there is no need for it in the requirement. The system WILL prevent fraud.
If practical, the XYZ system will let the adjudication result show on a report.
Normally the XYZ system should allow the user to login during the day.
The XYZ system will provide a login box for the user to sign into the application.
Reporting from the XYZ system will start and complete in a timely manner.
The XYZ system may let the user navigate to another application during the application process.
The XYZ system will optionally show either the first or second detail screen depending on if the user has selected the open action.

Automated Requirements Measurement (ARM)

In the late 1990s the National Aeronautics and Space Administration (NASA) Software Assurance Technology Center (SATC) developed a tool to automatically analyze a requirements document and produce a detailed quality report. The report was based on statistical analysis of word frequencies at various structural levels of the document. The Automated Requirements Measurement (ARM) tool was further enhanced to include additional functionality such as custom definitions of quality indicators inputs for document analysis. The ARM weak phrase count is an indication of the extent that the specification is ambiguous.

The Basel RMT team used the ARM tool to check the NL quality of each requirements document. The tool located instances of weak language. Once run, the report was provided back to the BA to correct any weak statements. Programme Auditors were satisfied that ARM was being used to remove weakly stated requirements from the specifications. Occasionally we were asked to provide ARM reports to the auditors as evidence that weak requirements were being addressed.

Good requirements have the following properties:

Completeness - Include requirements that are testable and can be validated Exclude requirements that will not be implemented.
Consistent - No conflict between requirement statements.
Correct - Must identify conditions and limitations of all situations that the capability will provide.
Modifiable - Requirements grouped together can be modified as one. Avoid unrelated requirement concerns.
Testable - Must be stated in such a manner that a quantitative assessment can derive a pass/fail indication.
Traceable - Must be uniquely identified by number and context.
Unambiguous - Interpret the requirement one-way.
Understandable - Meaning of each requirement is easily grasped by all readers.

We used to say that a good requirement document was well written if it passed the "pedestrian test": a pedestrian finds a copy of it on a park bench, reads it and understands the content.

NON-FUNCTIONAL REQUIREMENTS

Managing non-functional requirements on Basel.

The non-functional requirements specify the service levels the system must satisfy, the required non run-time properties of the system, and the constraints to which the system must conform. Non-functional requirements may apply to the system as a whole, to parts of the system, or to particular use cases. Non-functional requirements consist of the following:

Service level requirements (SLRs), define run-time properties that the system must satisfy.

SLRs include:

Capacity and performance (volumetrics).
Availability.
Security.
System management.

Other required (non run-time) properties of the system, included:

Portability.
Maintainability.

Constraints to which the system must conform comprised:

Business constraints e.g., geographical constraints.
Technical standards.
Technical constraints, e.g., existing hardware, which DBMS must be used.

The purpose of the non-functional requirements section is:

To specify required properties of the system.
To define constraints on the system.
To enable early system sizing and estimates of cost.
To assess the viability of the proposed system.
To give a basis for designing the operational models.
To provide input to the component design.

HP QUALITY CENTER

One further integration was between RequisitePro and an early version of HP Quality Centre (HPQC) (not sure what it's name was at the time). This was a plug-in on ReqPro that allowed a linkage between a requirement and the test cases on HPQC that validated the completeness of the requirement. The Test team (QA) managed HPQC and a group of QA staff. The team's manager was a recent hire from CGI and had a good amount of experience from his previous role.

Requirements Tool Integration

Each requirement needs one or more test cases to prove that the requirement was met by a technical solution and is performing as expected. For example, a requirement may be that a screen input field only accepts values between 1 and 10. A test case will test positively that entries between 1 and 10 work, but will also test negatively that 0, negative numbers and numbers greater than 10 will fail.

If the test passes, then a TEST PASS flag is set on ReqPro to indicate that the requirement is satisfied. The evidence being the test results. If the test fails, then the flag is set to FAIL; the requirement has not passed the test and is incomplete.

On ReqPro, reports could be run on which requirements passed or failed testing. It was a good indication of progress.

Only when all requirements have a TEST PASS, can the specification be locked down. I asked the Test Team Manager to track on HPQC the reason for the test failure. The technology team who implemented the solution to the BA's requirement, or the BA should know the reason for failure. Was it, a lack of the BA's understanding of the requirement, improper technical implementation of the requirement, incorrect information provided by upstream stakeholders to the BA, incorrect QA testing, or something else? This would have given opportunity to remediate the causes of test failures. However, this was never implemented and I felt we lost the opportunity to identify what was causing the test failures.

ITERATION PLANNING

Several aspects of the requirements management approach used on this programme were influenced by NASA's approach to software development. While at General Electric, in creating a software development group, I reviewed several approaches to managing software projects. As our client base were largely Fortune 100 firms, I read up on different approaches to managing software projects. The ARM tool was certainly one of the most obvious items borrowed from NASA's software development public tool suite.

NASA's projects were typically large dollar endeavors with very specific requirements. Conformity to requirements and safety aspects of the delivered product were prioritized. Some of our clients were large firms with large projects and an expectation that our software development approaches were well established. I expected that our projects would likely be ran using a waterfall approach. Although it worked for some, we found that most clients required a lighter (Agile, Spiral, etc.) approach to their projects.

Whereas an Agile approach is ideal for building applications whose requirements are evolving; almost an experimental approach, this would not be the case with the Basel programme. Agile was in its infancy at this time, especially when most banks lagged adoption of new methods. Plan based methods for project management was the standard in banking. As one CIBC executive mentioned: "why change an approach that for years has been working for us?".

For Basel the regulatory requirements were firmly stated in the form of paragraphs. Given the number of paragraphs, the immensity of the work to be performed and the tight timelines, a more formal approach was needed with the appropriate controls to ensure the first cut of requirements were well documented and well understood. There was no time for second chances. Therefore a waterfall approach with all the formality of a large programme was the better fit. It was also the methodology of choice for some of the larger consulting firms. This being a regulatory project and under the oversight of OSFI, it required demonstrable controls, process and documentation atypical in smaller projects.

When the RMT team was asked to implement a requirements process to ensure high quality requirements were delivered, immediately I thought of NASA's approach to managing large software projects. Unknown to anyone outside of RMT, some of NASA's ideas were incorporated into RMT's processes.

One such idea was partitioning the requirements document creation into four iterations; stages. Each iteration had an expectation on what the BA and BSA would have to accomplish in the document. Document sections per iteration were either mandatory or optional. Some document sections were allowed to evolve through all four phases before finally being mandatory at Iteration 4.

The format of the requirement document itself was quite standard. It's typical of most requirement documents BAs had previously used. Below is a view of the requirement format and the expectation of documentation completion by each iteration. I was aware of one project using a "Use Case" approach for requirements but by far, everyone used the standard template.

Iteration Planning for Business Specification Documents

The second idea borrowed from NASA was documented business specification entry and exit criteria per iteration, similar to the diagram below. Unfortunately I don't have access to the original RMT documentation which describes the success conditions per phase. BAs were instructed on what sections of the requirements specification to complete at each iteration. BAs therefore worked with a timebox approach to completing each iteration. They knew the deliverable documentation expectations of each iteration and could communicate to their PMs when they could complete the work; assuming all went well and there was no re-work.

Sample - NASA Entry and Exit Conditions for Requirements

Similar to NASA's approach for software development, business specification reviews were introduced. This was checkpoints at Iteration 2 and 4. These were formal specification review meetings scheduled by RMT and attended by all project stakeholders.

Roles for Completing Business Specifications

The Basel Project BSAs and BAs drove the first iteration:

Task ID Description of Task Role in Iteration 2-4

Review reference documentation – Sharepoint/ReqPro. N/a.
Validate proposed solutions.
Meet with business SMEs to drive out requirements (involve Platform Co-or). Continued role.
Populate the requirements to Business Specifications &/or Use Case documents. Continued role.
Create As-Is diagrams – (remain somewhat static after production).
Create To-Be diagrams – (dynamic through 4 iterations).

Business Analyst, Basel Project Team – drove iterations 2-4

Task ID Description of Task Role in Iteration 1

Review reference documentation – Sharepoint/ReqPro Review
Validate proposed solutions Involved
Meet with business SMEs to drive out requirements (involve Platform Co-ordinator)
Populate the requirements to Business Specifications &/or Use Case document
Create As-Is diagrams – (probably remain somewhat static after production)
Create To-Be diagrams – (probably dynamic through 4 iterations)

Business Systems Analyst – IT Application – involved from step 1 in BA function in iteration 1.

Task ID Description of Task Role in Iteration 1-4:

Meet BA & BSA (Basel Teams) on business specifications, diagrams and provide questions and feedback participative
Walkthrough of Specifications and Diagrams with Basel BAs & BSAs
Build IT application specific specifications and other required documentation
Build IT application test plans from Business Specifications &/or Use Case documents

CHECKPOINT REVIEWS

The sole purpose of this meeting was to ensure that all stakeholders agreed that the requirements gathered to date represented an accurate and complete set of requirements. The project artifacts gathered to-date needed to be packaged and e-mailed to meeting participants for review three days in advance of the meeting. This gave participants time to review the documents in advance of the meeting.

Attendees (stakeholders) were:

BASEL Project Manager, Meeting Facilitator
IT Project Manager
IT Business Systems Analyst (BSA) Representative (optional)
BASEL Business Analyst (optional)
Technology Design Authority (TDA) Representative
Business Design Authority (BDA) Representative
Qualification Representative
Business Representative
Test Team (QA) Representative
Requirements Team Representative
Data Steward Representative

As the requirements had to satisfy all stakeholders. It was the norm that if document changes were required, depending on the severity of the changes, either a new meeting was called after the document was updated, or it was e-mailed out for review and sign-off if only minor updates were required.

A quality grading system based on GREEN, YELLOW or RED was assigned to each section of the document and to the overall document by the checkpoint reviewers. Yellow meant that some changes were required and should be addressed in next iteration but was OK to proceed. Red denoted that the document needed significant changes that must be committed to before proceeding further.

Suggested materials for the Checkpoint Review meetings were:

Agenda — outline of review material.
Introduction — purpose of system and background of the project.
Requirements summary — review of top-level (basic) requirements developed to form the specifications:

Background of requirements — overview of project characteristics and major events.
Organizations that provide system and support input and receive system output.
Data availability — frequency, volume, and format.
IT sub-projects driven by this business level project.
Requirements for computer storage, failure/recovery, operator interaction, diagnostic output, security, reliability, and safety.
Requirements for support and test software — Test programmes and utilities if needed.
Overview of the requirements and specifications document — its evolution, including draft dates and reviews and outline of contents.

Interface requirements — summary of human, special-purpose hardware, and automated system interfaces, including references to interface documents.
Performance requirements — system processing speed, system response time, system failure recovery time, and output data availability.
Environmental considerations — Special computing capabilities, e.g., graphics, operating system limitations, computer facility operating procedures and policies, support software limitations, database constraints, and resource limitations.
Derived system requirements — List of those requirements that are not explicitly identified within the functional and non-functional specification representing constraints, limitations, or implications that must be satisfied to achieve the explicitly stated requirements.
Operations concepts — Business process diagrams and use cases scenarios. Sample input screens and menus; sample output displays, reports, and plots; critical control sequences, if available.
Issues, TBD items, and problems — a characterization of all outstanding requirements issues and TBDs, an assessment of their risks (including the effect on progress), and a course of action to manage them, including required effort, schedule, and cost.

Checkpoint Review Entry Criteria

The Business specification document should be entered into ReqPro.
Business Requirements should be flagged in ReqPro and linked to a Basel gap.
Project scope should be validated with other related projects. Any changes in scope or deliverables from the Charter should be detailed in the Business Specification document section 3.2. If scope has been moved to another project, that should be indicated. If there is no change, the section should state NO CHANGE.
Requirement interdependencies should have been validated with other related projects.
Data requirements should have been validated with other projects.
Operational reports should be listed in the reporting requirements section, and validated with the reporting project PM.

Checkpoint Review Exit Criteria

Program teams have completed scorecards and provided them to the project managers.
A formal checkpoint meeting has been held to review program team evaluations.
Written feedback has been provided to program teams outlining whether a change will be made and the timeframe for making the change.
Stakeholders and program team leads have signed off on the Business Specification document.
Requirements have been baselined for change control.
The Business Specification document has version control.

Following the checkpoint meeting, the BASEL project team analyzed all pending review items (RI), determined whether requirement changes were necessary, and revised the requirements specification document accordingly. The updated document was sent to the signatories for approval. Once approved, the BSD became a Controlled Item (CI).

The following questions determined whether the requirements and specifications were ready to be given to the IT sub-project team for analysis:

Do specifications exist for all requirements for which information is available? Have TBD requirements been minimized?
Have external interfaces been adequately defined?
Are the specifications consistent in notation, terminology, and level of functionality, and are the business rules compatible?
Are the requirements testable?
Have key exit criteria been met? That is, has the requirements and specifications document been distributed, has the review process been successfully completed, and have all pending review items been answered?
Have all signatures been collected?
Have copies of the signed-off document been distributed to meeting attendees?

When the answer to these questions was "yes," the requirements phase was complete.

Challenges

The checkpoint process was not popular with BAs or PMs. There was quite a lot of pushback by the project BAs and PMs whose requirements were being reviewed. Understandably, in most cases this led to additional work because the requirement specification was lacking in many areas. This required BAs to spend time correcting the specifications, re-scheduling reviews and delaying progress further given the push for the programme to meet the regulatory deadline.

Some PMs became quite vocal objectors of the process. However, once the programme management woke up to the reality that the requirements were not evolving to the required specificity, it became clear that the checkpoint process was required.

Often, as checkpoint review feedback was given to PMs and BAs during the meetings, we observed they became defensive, as if it was a personal attack on themselves. We noted that reviewers often mentioned "Your document" or "You failed to". We instructed the reviewers to de-personalize the feedback. For example, use "the document" or "the specification needs to be", the idea being to take the "you" out of any feedback. This small change made a lot of difference in "lowering the temperature" of checkpoint meeting attendees.

PROBLEMS

Requirements Issues at Iteration 2

During the first requirements review process (Iteration 2) it was realized that there were problems with the requirements. This put a temporary halt on the requirements gathering as we assessed what went wrong. It necessitated a review of what was working well and why the requirements were incomplete.

The original requirements specification templates were created by IBM and the Project Management Office (PMO). The RMT team believed these were approved templates and would be easily understood by the BAs. However, the BAs (some being contractors) were not always familiar with the business and this led to gaps in understanding of what needed to be specified to close the gaps. The BDA group were the most familiar with the business. Some problems were simply processes not being followed; traceability missing in some cases.

Iteration 2: Review and Lessons Learned

Observed incomplete documentation of some functional requirements.
Some requirements were not linked to gaps.
Some requirements did not link logically to a gap.
Some functional requirements were not defined in sufficient detail. The programme talked about 1:1 mapping from requirement to gap. Gaps were not highly detailed but requirements must be.
Some process maps were not detailed enough.
Some requirements were difficult to understand.
In some cases, requirements were not linked to processes (orphaned).

Root Causes and Solutions for Remediation

Cause: Insufficient/incomplete guidance supplied by programme teams.
Solution: Clarify content required for Iterations 2, 3 and 4. Review the Business Specification template with the teams to ensure everyone has the same expectations of content.
Cause: Insufficient/incomplete/inconsistent definition of to-be business processes.
Solution: Guide teams on process definition which will assist them in defining functional requirements. BDA will facilitate workshops to assist project teams to complete process modeling.

Impact

This halt caused much upheaval with the BAs who were well on their way writing with their requirements templates. A new requirements template was created. BAs were not happy as they understood that the new template would require more work, more detail, on a project whose timeline was already tight. programme management worried that timelines were imperiled by this delay and the need for more detailed requirements.

IBM threatened to bring back their requirements experts, effectively side-stepping the RMT. In the end it didn't happen, RMT had already improved the processes IBM left us with. RMT with guidance from the Business Design Authority (BDA) group subsequently updated the existing templates to provide the required level of detail. Additionally, the BDA stepped in and provided high level diagrams to start the BAs with diagrams they could further elaborate.

An example of the changes made can be seen below. The first diagram is the traceability model that was prescribed prior to realizing the problems at Iteration 2. Here we have one requirement traced to one gap. One requirement (high level) may have multiple child requirements (detailed).

Original Traceability Diagram at Iteration 2

The new traceability model below shows the new Level 1 (L1) and L2 models introduced by the BDA team. This example shows the model for two requirements sharing the same Basel gap and sharing the same activity models within Rational Rose. One gap could have multiple requirements to address it.

Updated Traceability Diagram for Iteration 3 and 4

Boot Camp

One of the practices established early on, once the requirements specification was stable, was a "Boot Camp" session for any BAs or PMs joining the Basel programme. The purpose of this was to familiarize new programme participants with the requirements specification, processes and the tools required to manage requirements. There was a two hour session for BAs and a shorter session for PMs. Some participants had never participated on a large programme. The level of process formality was new to them. The training provided them with knowledge they could apply to other large programmes.

Boot Camp meeting invite

The agenda for a Boot Camp meeting was:

The requirements development process for the BASEL II project
Where requirements documents are located
What are requirements iterations and checkpoints
What’s in/out for each requirements iteration
The traceability model and why are we using it
How to use the Requirements Management Plan
How to complete a Business Specification Document (BSD)
Writing clear requirements in natural language
Process model decomposition for Level 3 and Level 4
Using Rational RequisitePro to create business specifications
How to publish requirements, assumptions and business rules
How to create a sandbox for experimenting within RequisitePro

CHANGE MANAGEMENT

Eventually business requirements become complete and fully tested (are stable). In these cases the business specifications are locked by RMT to prevent any further changes. Whenever controlled business specifications are locked or unlocked, the requirements team issues a Requirements Change Note (RCN). The purpose of the RCN was:

It is a method for the requester and RMT to track and acknowledge the opening and closing of project business specifications.
It is created by RMT Lead and copied to project PM, project requester (if not same as PM), Architecture Lead, Qualifications Lead, Change Manager and RMT team.
It raises visibility to PIO representatives that changes are being made.
The project PM receives a copy of the RCN as acknowledgment.
It provides an audit trail of acknowledged requests made to re-open/close requirements after sign-off.

Requirements at Iteration 4 represent the final version of the BSD. Configuration Items (CI) were RequisitePro artifacts under change control, such as the BSD.

Exceptions

There were cases where we recognized that putting some projects through the requirements process would result in them missing the deadline and in some cases holding up other dependent projects. In such cases the PM could apply to programme management for an exception to the process. Programme management would meet with the PM to understand the reason and whether an exception could be granted. Effectively, the programme would assume a certain level of risk by trusting that the project was creating quality requirements. I recall three cases where exceptions were granted. Everyone else had to follow the process.

EPILOGUE

RBC's Basel II was a great success. All the regulatory requirements were met. RBC acquired a new risk management system as part of the programme. The programme cost was budgeted at $140M but came in at $135M. Other banks struggled with Basel II. For example, one bank exceeded their budget and it was common knowledge on the street that other banks were challenged with Basel II compliance. For some banks it was an extensive overhaul of their risk monitoring systems and processes.

The programme ended with over 15,000 unique requirements with full traceability to the original Basel paragraphs.

With the program ending, the full time staff moved to other projects and jobs within RBC. The nature of these large projects is that as staff, you are moved to the project on a full time basis. However, when the project ends, you have no home! You have to look for a new job and a department that will take you. It's starring all over again and selling your skills internally in the hope that someone will hire you. You have three months to find a spot within the bank, otherwise....

My VP found himself looking for his next opportunity. When no appealing alternative was presented to him, he decided to retire.

The Test Team manager was promoted to a QA Director role for RBC's technology area. He led the RBC QA area for many years.

I did a few presentations to a couple of executives at RBC on how the requirements phase was managed for Basel. It was all well received and I hoped that some of the great practices that led to our success would be adopted by other teams. I was never sure they were. I did come across a presentation from one of the consulting firms we used that showed their use of the ARM tool; no doubt having seen its application on Basel.

I was contacted by another programme to be the Requirements Lead, but I declined, now wiser to the career risks of being on programmes.

Before he left, my VP made the case to his executive that they should assist in finding me a position within RBC. Hence, through his efforts, I landed a senior management position within Payments and Trade (PnT) managing client payment system integrations into RBC's payments infrastructure; on the business side. I had a wonderful technology team supporting our area. Being on the business side instead of a technology area, I found the work pace to be more relaxed. Overall, I experienced a better work/life balance.

Another irony was that as my PnT VP moved to take a new position in Capital Markets, the PnT business area was aligned to a technology area led by the former Basel IBM programme lead who was now a full time RBC VP! Full circle.

Overall the programme was a great success for RBC. The programme was highlighted as the project of the year at RBC. During the programme I received a Star Award in recognition for the requirements management work.

APPENDIX

ARM OVERVIEW

The objective of the Automated Requirement Measurement Tool (ARM) is to provide measures that can be used to assess the quality off a requirement specification document. The tool is not intended to evaluate the correctness of the specified requirements. It is an aid to "writing the requirement right, "not writing the right requirement". ARM Tool Main Menu

The ARM tool scans a file designated by the user as the text file that contains the requirements specifications. During the scanning process, the ARM tool searches each line of text for specific words and phrases. These search arguments (specific words and phrases) are considered to be indicators of the document's quality as a specification of requirements.

While the source file is being scanned, an ASCII text report file is created in the same directory as the source ".txt" file designated by the user. The ARM tool gives the report file the same prefix name as the user's source file and adds an extension of ".arm". This report file contains a summary report and detailed reports for specific quality indicators.

By 2011, NASA discontinued the ARM tool. There have been recent (2024) attempts to re-create its functionality.

Once the Basel programme terminated I found a consultancy firm, that worked on the programme, was also using the ARM tool; no doubt having learned of its existence from the programme. Subsequently, no other programme at RBC used this tool.

Reference Links

Below is a list of links relating to the items discussed above.

click here - OSFI, Office of the Superintendent of Financial Institutions. Supervises federally regulated financial institutions and pension plans to contribute to public confidence in the financial system.
click here - BIS, The Basel Committee on Banking Supervision (BCBS) is the primary global standard setter for the prudential regulation of banks and provides a forum for regular cooperation on banking supervisory matters. Its 45 members comprise central banks and bank supervisors from 28 jurisdictions.
click here - NASA, Software Assurance and Software Safety
click here - CMMI, ISACA CMMI Performance Solutions
click here - Crosstalk, The Journal of Defense Software
click here - Carnegie Mellon University, Software Engineering Institute. At the SEI, we research complex software engineering, cyber security, and AI engineering problems; create and test innovative technologies; and transition maturing solutions into practice. We have been working with the Department of Defense, government agencies, and private industry since 1984 to help meet mission goals and gain strategic advantage.

Resources

Below is list of documents that have been uploaded to this site and are available by clicking on the links below. I've included the documents instead of the links to NASA as my worry is that over time these documents may be deprecated from public sites due to their relevance in today's software development practice.

click here - NASA SEL-81-305 Recommended Approach to Software Development, Revision 3, June 1992
click here - NASA SEL-84-101 Manager's Handbook for Software Development Revision1, November 1990
click here - NASA-GB-001-94 Software Measurement Guidebook Revision 1, June 1995
click here - NASA-GB-001-95 Software Process Improvement Guidebook Revision 1, March 1996
click here - Calculating Costs of a Software Error Prevention System, Parasoft
click here - Data Analysis Center for Software (DACS) Agile Software Development State of the Art report, January 2003
click here - David J. Schultz, january 2001, A Comparison of Five Approaches to Software Development
click here - Travassos et Al., 2019, Reading Techniques for OO Design Inspections
click here - NASA-SATC, William M. Wilson et Al. Automated Quality Analysis of Natural Language Requirements Specifications (ARM)
click here - NASA-SATC, NASA copy of the ARM Tool Installation Package (ZIP)

Compiled on 05-19-2024 17:29:13

MANUEL DUARTE

Navigation

Managing Natural Language Programme Requirements for Basel II