1. Requirements Lifecycle Management
Sogeti Presentation
01/01/2019
Requirements Lifecycle Management
Better requirements for testing
(without testing doing all the work)
Richard Ammerlaan – Sogeti UK
© 2007 Sogeti

2. Sogeti: A Worldwide QA & Testing Leader
Sogeti Presentation
01/01/2019
Sogeti: A Worldwide QA & Testing Leader
Sogeti Group
Europe & USA
£ 800 m rev.
17,000 staff
USA
France
Spain
Sweden
Belux
Germany
Switzerland NL
Denmark UK
Ireland
India
Norway
Testing revenue
Worldwide: £ 67 m
Professionals
Over 1,500 experts
Providing worldwide Testing standards
Copyrights TMap® and TPI® brands
Dedicated R&D on new developments
SOGETI is the testing services arm of Capgemini in the UK. Our role is to win and deliver on IT testing programmes – where risk-based rigorous testing of business-critical functions is a key element of client’s assignment.
SOGETI UK transforms the IT testing and Quality Assurance performance of organisations in both public and private sectors. Clients call on us when they need objective advice and pragmatic testing services as part of strategic IT programmes; from achieving value from multi-sourced testing centres, through to risk-based and structured specialist test execution. Our collaborative approach is grounded in our open and innovative methodologies that manage risk and produce identifiable and measurable results.
As the largest testing service in Europe/USA, Sogeti provides the reassurance that a business can achieve its IT project and programme goals, by reducing the risk of IT failures, improving quality of deliverables and ensuring the delivery of the business’ expectations
Sogeti in the UK is committed to testing – it is our core business. Unlike other full-service providers with testing practices or business units, in which testing is a peripheral activity, we focus on testing with our dedicated resources and facilities. The SOGETI Group has been testing for over 35 years.
Sogeti’s ‘best in breed’ open testing frameworks flex to meet customer requirements. Every testing service provider has its own well-defined testing process, but Sogeti’s is different. Sogeti’s TMap®, a modular methodology, is designed to be consumed however the client wants, integrating with multiple hardware, software and networking components. TMap® was designed to ensure that the stringent targets of cost, time to market and quality are hit and is continually being refined in line with experience in the field. As a result, it provides greater reassurance and control freeing the client to focus on other pressing business IT issues and has been embraced by many as an industry standard.
Sogeti operates as an independent specialist testing function within the Capgemini Group. We apply rigorous and objective assessment of clients’ testing processes and activities, helping them to ensure that that they have the best possible testing performance and results.
As the largest testing service provider in Europe/US, with over 1,700 dedicated professional testers in 200 locations worldwide, Sogeti has access to the largest international professional resource pool with deep testing tool expertise. Sogeti’s testers are skilled in a broad range of vendor tools (eg IBM Rational and HP Mercury) and technologies (eg SAP, SOA) and are experienced in working in a multiple vendor/supplier environment. What are the benefits? We bring experience and expertise to the ‘game’ which means that clients’ projects run more smoothly from day one. Moreover we share the skills and knowledge with clients to their benefit. Our testers are dedicated, trained and committed – not developers on the bench.
We take a business-driven risk and strategic approach. By taking a more strategic and inclusive approach to the value of testing within the context of the overall QA roadmap, and placing the customer’s business drivers and core business issues at the heart of our tailored solutions, we ensure that the most essential risks are addressed and the broader business’ expectations are met.
Working in a flexible and partnership approach – whether in-house or multiple vendor - means high levels of client satisfaction. We work with a large number of listed blue-chip companies around the world and beyond all the scientific quality metrics applied to our engagements; we know that quality, after all, is what our customers demand. Very early in each and every engagement, Sogeti sets expectations together with our clients on the project outcome … and then uses its own customer approval assessment to validate client satisfaction on a project by project basis. Finally we make the findings public. Not surprisingly SOGETI achieves an average customer satisfaction of 92% or higher.
We provide a quality service at competitive rates – based on an onshore-offshore blended rate, by using a distributed delivery approach, including Capgemini’s global delivery model Rightshore™, passing on the savings to our clients.
01/01/2019
© 2007 Sogeti

3. Contents Requirements, who cares?
Sogeti Presentation
01/01/2019
Contents
Requirements, who cares?
Requirements from a project point of view
What do requirements mean for you?
Requirements from a Testing point of view
Testing & Requirement lifecycle Management
Extending the role of Testing
01/01/2019
© 2007 Sogeti

4. Requirements, who cares?
Sogeti Presentation
01/01/2019
Requirements, who cares?
Test Management Summit 31 Jan 2007
“Future for Test Manager Skills” session (Stephen Allott)
Methodology
Requirements Based Testing
Risk Based Testing
Business Driven Testing
Tool vendors
Business Requirements Management
Application Lifecycle Management
Requirements driven Quality Management
Technology
Agile-like processes
SOA
Multi-sourcing
Test Management Summit 2007
“Future for Test Manager Skills” session: going into the required skill set for a test manager in the future there was a tendency to claim everything including managing requirements
Methodology
Requirements Based Testing / Business Driven Testing / Risk Based Testing: what to test and when to test it
Tool vendors: linking different parties/process and even locations, everybody sees the importance and the need for information
Business Requirements Management
Application Lifecycle Management
Requirements driven Quality Management
Technology
Agile-like processes: what are the requirements, when are they created and who manages them
SOA: who owns and who pays, multiple departments/services/business processes operate a component, who’s in charge of requirements/design/development/testing?
Multi-sourcing: requirements are at the base of contract negotiations
01/01/2019
© 2007 Sogeti

5. Requirements from a project point of view
Sogeti Presentation
01/01/2019
Requirements from a project point of view
Steering committee
Business
Executive
User representative
Supplier/IT
Executive
Project
Project manager
Quality assurance
Architects
Users
Analysts
Designers /
Developers
Testers
Implementation
specialists
Management
(infra, tech, func)
Classic example of creating requirements (and maintaining as much as the project schedule will allow)
Traditional requirements definition & management role
01/01/2019
© 2007 Sogeti

6. Requirements from a project point of view
Sogeti Presentation
01/01/2019
Requirements from a project point of view
Business requirements
Steering committee
Business
Executive
User representative
Supplier/IT
Executive
Project
Project manager
User requirements
System requirements
Quality assurance
Architects
Business requirements
Business requirements
System requirements
Users
Analysts
Designers /
Developers
Testers
Implementation
specialists
Management
(infra, tech, func)
Major stakeholders in requirements definition and management, involved early/too late or not al all
But where should requirements management sit according to different stakeholders
Sogeti seminar/training series responses
60% - Requirements Management represents the interests of the business
68% - Architects should collect, analyse and specify requirements
Requirements based testing/Risk based testing is claiming an increased role in requirements ‘handling’ that can result in anything from just managing a requirement management system (as part of general tool support) to playing a major role in documenting for Agile-like processes
User requirements
System requirements
User requirements
Different stakeholders for different requirements
01/01/2019
© 2007 Sogeti

7. What do requirements mean for you?
Sogeti Presentation
01/01/2019
What do requirements mean for you?
Importance for testing …
Experiences
01/01/2019
© 2007 Sogeti

8. Requirements from a testing point of view
Sogeti Presentation
01/01/2019
Requirements from a testing point of view
High
(ALM)
Process/tool maturity
Technology driven
Maturity
Process/tool combo
Disparate
Process driven
Any requirements discussions from the point of view of testing suffers from two conflicting efforts:
Increasing tool support, often introduced as part of ongoing test automation (including test management) since they complement tools already in place
Process driven change, increased attention for testability of requirements (as part of contract negotiations etc)
Dangers include over reliance on tooling without proper placement in the organisation (identifying persons/roles responsible for introducing/maintaining tools). Over reliance on process can lead to a lethargic reaction to yet another set of processes.
Key to successful managing is correct placement of responsibility and when necessary also to create the required roles within the organisation.
Level of
Tooling
Level of
Process
Test Method
High (RLcM)
01/01/2019
© 2007 Sogeti

9. Requirements from a testing point of view (2)
Sogeti Presentation
01/01/2019
Requirements from a testing point of view (2)
Steering committee
Business
Executive
User representative
Supplier/IT
Executive
Project
Project manager
Quality assurance
Architects
Users
Analysts
Designers /
Developers
Testers
Implementation
specialists
Management
(infra, tech, func)
In the end the facilitating role for requirements definition becomes similar to other QA roles.
Requirements managers can operate on a company/program or project level in the same way QA does in having responsibility for managing a specific type of information, influence in setting standards and enforcing them when business goals are threatened.
Where to place requirements management?
01/01/2019
© 2007 Sogeti

10. Testing & Requirement Lifecycle Management
Sogeti Presentation
01/01/2019
Testing & Requirement Lifecycle Management
Integrated QA & Test Strategy
Requirements
Lifecycle
Management
Testing
Operational QA (product and process)
Requirements development and management do not stand by themselves. As discussed in the previous chapter this applies to the relationship with any system development methodology. Specifically this applies to the relationship with integral quality control.
Integral quality control aims at all quality aspects of the process of delivery and maintenance, see figure 10 integral quality control. Requirements Lifecycle Management, Operational QA[1] and testing are brought together under the ‘integral QA & test strategy’. This strategy contains coherent quality measures regarding the processes to follow and the products to deliver. It is aimed at effective and efficient application of quality measures.
[1] QA = quality assurance meaning ‘taking all measures needed to ensure the (IT-) product will meet the expectations of the customer (in terms of time, money and quality)’.
Determine the quality of requirements
The RLcM approach is explicitly aimed at reaching quality of requirements. The measures are:
application of a structure for requirements that defines levels of requirements, requirements attributes and a set of standard properties for non functional requirements;
application of a structured process for requirements development including validation;
definition of requirements management activities.
In chapters 3 and 4 these topics are explained. QA officers are consulted when setting up the RLcM processes and the validation of requirements can be facilitated by the QA role.
Requirements and product risks
As mentioned in the introduction an integral quality strategy is a coherent set of measures for QA and testing. Carrying out a product risk analysis is a prerequisite for setting up this quality strategy. The project manager will aim his efforts on the parts of the product that form the greatest risks.
What now are the process and product risks of the project? To determine the product risks, the most interesting for this paper, the following question has to be answered:
“What is the risk if we take product [x] in production?”. There are two important factors that determine this risk and they are the chance of failure and the damage caused by failure.
The chance of failure is determined by the chance of errors in the application multiplied by the frequency of use of the application.
More information regarding the product risk analysis can be found in the book TMap Test Topics [Koomen 2004].
Business, user and system requirements are very suitable to use as a foundation for determining the risks. They contain important information for each of the risk factors mentioned:
Damage: the priority of a requirement is an indication for the component damage. If a requirement has a low priority the damage of incomplete and/or incorrect implementation will be lower than if it has a high priority. The priority of the requirements has been determined during requirements analysis (requirements development), for example by means of the MoSCoW model.
Frequency of use: frequency of use is an attribute of processes and activities that have been identified as user requirement. It makes sense to include this attribute for user requirements.
Chance of failure: the chance of a failure is determined by a lot of factors, complexity being one of them. The complexity can be based on the system requirements, for example algorithms and interfaces. Other factors are the infrastructure, organisation of development activities, knowledge and skills, time pressure, etc.
Damage, chance of failure and frequency of use can be categorised: 1 (low), 2 (medium) and 3 (high). Multiplying this gives the (relative) product risk number.
Development and maintenance
Process improvement
01/01/2019
© 2007 Sogeti

11. RLcM Requirements structure
Sogeti Presentation
01/01/2019
RLcM Requirements structure
User requirements (what)
Business requirements
(why)
System requirements (how) F u n c t i o a l
Non f u n c t i o a l
Attention points
Functional versus non-functional;
Detailed (system) requirements, look for more then just software requirements: - process requirements; - infrastructure requirements; - software requirements; - operations & maintenance requirements.
01/01/2019
© 2007 Sogeti

12. Requirements management
Sogeti Presentation
01/01/2019
Requirements management
Requirements Lifecycle Management
Requirements management
Elicitation
Requirements development
Version control
Requirements status tracking
Requirements tracing
Change control
Analysis
Specification
Validation
Baseline
The first challenge in the lifecycle of requirements is describing and determining the requirements (requirements development). This should result in requirements that are SMART and coherent, both between the levels of requirements as within these levels.
Requirements management contains control activities like change and version management. These activities are not limited to determining the requirements, but start before the requirements are described.
In order to do requirements management in an effective way a number of criteria must be met by the requirements development process. An example is the use of a requirements structure as presented in the previous chapter.
The dynamic lifecycle of requirements determines the relationship between requirements development and requirements management. That is the reason for the name Requirements Lifecycle Management. This white paper mainly address requirements within projects The lifecycle of requirements however does not stop at the end of the project but continuous in the management and maintenance phase.
4.2 Requirements development
Describing and determining requirements (requirements development) is a challenging process that must result in requirements that are SMART and coherent.
The following activities [Abran 2001, Wiegers 2003] are executed:
• gathering requirements (elicitation);
• analysis of requirements;
• specification of requirements;
• validation of requirements.
These activities are placed at the level of requirements. The reason for this are the relationships between these levels. Business requirements (objectives) guide the user requirements (processes). At the various levels different stakeholders are involved and there are various ways to gather the requirements. Possibilities are interviews, workshops and document study.
The result of requirements development is the baseline, a collection of agreed requirements that enters the next phase. This may be a system development phase, but it is also possible that the requirements must be specified on a more detailed level. Requirements development is iterative in nature, regardless of the methodology used. Iterations will always be necessary to clarify requirements. This is also caused by the relationships between the various levels, leading to fine tuning of requirements at a higher level.
4.2.1 Requirements elicitation
Requirements should be gathered, they don’t present themselves.
The term elicitation implies an active search and this active meaning is in it’s place here because action must be undertaken to gather them.
Gathering requirements, at each of the levels, starts with an inventory of stakeholders and sources (people, documents, registers, visit to the shop floor, …).
For the three levels:
• business requirements
- stakeholders: business management (business executive and senior user);
- sources: the stakeholders, policies (documents), business plan, business case and project brief;
• user requirements
- stakeholders: department managers / team managers (senior user), process owners and representatives of the end users;
- sources: the business requirements, the stakeholders, business architecture, information architecture, existing requirements, existing process descriptions, use cases, manuals and visits to the shop floor;
• system requirements
- sources: the business and user requirements, the stakeholders, information architecture, system architecture, existing requirements, user manuals, standards and guidelines (security, maintenance, etc.) and visits to the shop floor.
Understanding who the stakeholders and sources are helps to determine the approach to use. Possibilities are interviews, brainstorm sessions, workshops, structured analysis of document, visits etc.
4.2.2 Requirements analysis
Requirements analysis has to result in an unambiguous understanding shared by the stakeholders, matter specialists and requirements analysts . The analysis can be done by writing down a detailed description of the requirement, making diagrams like context diagrams and process flows. Prototyping is also a way to clarify the requirements.
Part of the analysis is determining the relationships between requirements, especially between levels, and determining the priority of each requirement. The MoSCoW classification is one of the possibilities to determine priority.
MoSCoW makes it possible to distinguish requirements that can not be left out and have to be delivered at the beginning and those that are less important and may be delivered later on. This information is crucial for the planning of development and testing activities.
Requirements will have to fit within the current architecture, this has to be verified. However, there is also a possibility that requirements will lead to new agreements on the architecture and to determine the project start architecture.
4.2.3 Requirements specification
Requirements specification makes information complete and usable for others.
For each requirement the attributes as discussed before (identification, version, description, priority, status, source, owner, relationships and stability) are recorded.
4.2.4 Requirements validation
Requirements validation results in what we call the quality of requirements.
The requirements reflect the needs of the stakeholders and are supported by them. For developers and testers they form the foundation of their activities.
Validation means that the stakeholder verifies if the requirement actually describes what is necessary for his work. Validation also means checking the quality characteristics as described in paragraph 3.6 Quality of requirements. This check is done by all stakeholders and parties involved.
It is important that validation is carried out by stakeholders, developers and testers together. The questions and answers may be of relevance to all involved.
For testers a good approach for validation is to develop logical test cases. Reading test cases by the person(s) who developed the requirement forms an extra check of the non ambiguity of the requirements.
4.3 Requirements management
Requirements management encompasses:
• explicit change management of requirements that have been agreed;
• version management of requirements, requirements documents and baselines;
• keeping track of and reporting on the status of requirements (requirements status tracking);
• managing relations between the requirements and between requirements and system development deliverables (requirements tracing).
Requirements management starts before requirements development. The first thing is to define the framework for developing and managing requirements, e.g. by getting agreement on the structuring of the requirements.
Requirements management is also involved during requirements development of the top level of the pyramid. Requirements change from day one. It is of the utmost importance that changes are recognized and recorded since every change may have consequences for planning and budget, especially if these changes concern new or changed business requirements. Changing user and system requirements have to be validated against the original objectives i.e. the original business requirements.
Changes are documented stating, amongst others, the reason for the change. This helps future discussions.
Changes in requirements and the baseline will continue to happen. A figure of 2% per month is common. This does not mean that all changes should be dealt with in the project, but it does mean that changes are documented and evaluated but they will only be added to a new baseline after an explicit decision.
4.3.1 Requirements change management
Change management is aimed at controlling the process of changing requirements and determining the impact of proposed changes.
Process control implies describing how and where to request for changes, who determines the impact and how decisions regarding requests are made.
The impact of changes first addresses the requirements themselves, it is aimed at investigating which requirements will change and the possible conflicts that may arise from the change. The second step is to determine the impact on the development, testing and implementation activities, and subsequently the planning.
For large projects we advise the use of formal procedures and a change control board. Smaller projects may use a less formal approach.
4.3.2 Requirements version management
Version management starts with determining the baseline. This may be a baseline for one or more levels of requirements, as long as it is clear which levels of requirements are developed. Overall, requirements on all levels are relevant since they form the foundation for development, testing and implementation.
Requirements management tools support version management for both individual requirements and baselines.
4.3.3 Requirements status tracking
Requirements status tracking is all about following and managing the status of the requirements. During the project process the status of a requirement will change. Examples of statuses are new, committed, designed, built, verified, dropped and rejected. The status is applied to each requirement individually.
Requirements status tracking allows for reporting on the progress of requirements at the various levels
An important part is reporting on the progress of requirements on the various levels (figure 8, steering information based on the status of requirements). Stakeholders receive information tailored to their situation, everybody for “his” level and “his” requirements.
Apart from reporting on status it is also important to report on trends, for example the number of changes and their origin, to give insight in the stability of the project.
4.3.4 Requirements tracing
Requirements tracing supports change management, in helping making the impact analysis, but it is also an independent activity in monitoring progress and quality.
At the end of the day an IT application must be delivered that meets the requirements. If this is actually the case will not only be determined at the end. Deviations that become apparent at the end of the project may cause a lot of repair activities (time and money). Insight in realising requirements is necessary during the project: the intermediate deliverables.
To establish this it is necessary that the various parties report on the progress of implementing the requirements. Parties may be forced to document the implementation by including each requirement, by means of it’s identification, in the deliverable/documentation (design, code, test case, …).
Analysis
Design
Build
Test
Impl.
01/01/2019
© 2007 Sogeti

13. Extending the role of Testing
Sogeti Presentation
01/01/2019
Extending the role of Testing
Static testing
Damage
and usage
PRODUCT
RISK
ANALYSIS
Chance of
Failure
The central themes for determining the quality strategy are requirements, risks and measures, aimed at both the product to be developed as controlling the (project) process to deliver the product. The risk analysis forms the foundation for the integral quality strategy.
The objective of the quality strategy is to reduce the risks to an acceptable level, balancing the risks and the costs for the mitigating measures. The second objective is to find the most important defects (errors) as soon as possible/against the lowest costs.
An important instrument is the Product Risk Analysis.
The PRA catalogues the relationship between the (intermediate) products of the system development activities and requirements that have a high risk.
These relationships indicate the possible instruments to check if high risk requirements are sufficiently covered.
The overview of these instruments and the risk assessment determine which measures are taken. Measures include intakes, tests, reviews and inspections.
The result of the strategy, QA- and testing measures, is presented in the form of a plan. In many cases both a Quality and a Test plan are delivered. Depending on the size and complexity of the project the test plan is subdivided in a master test plan and detailed test plans. Even if more plans are needed, it is important that all QA and testing measures are derived from the integral quality strategy. This is the starting point of effective and efficient actions.
Baseline
Process
requirements
Infrastructure
requirements
Software
requirements
Maintenance
requirements
01/01/2019
© 2007 Sogeti

14. Sogeti Presentation
01/01/2019
Any questions?
© 2007 Sogeti