QP-006 Requirements Analysis and Design

ConfidentialQP-006 Requirements Analysis and Design

Requirements Analysis and Design

Processes: Requirements Management, Requirements Development

Organization: Teamnet Group

Code: QP-006

Process/Procedure Owner: IT Solutions Manager

Document Revision: 2.3

Approval Date: 13-Feb-2015

137

1/37


Confidentiality Type:

Description

Type of Information Contained: Processes, Responsibilities , Input and Output documents, RACI matrix

Classification Type: Confidential

Distribution Control:

Type of CopyApplicable to:

Access TypeCompany Departments

Internal copy Teamnet Group All Permanent

Change Control:

Revision Revision Date Changes

1.0 26.04.2004 Initial version

1.1 22.07.2004 Revision

1.2 31.08.2007 Revision

1.3 15.11.2012 Revision

2.0 06.06.2014Revision according to CMMI Dev. Practices. The following procedures have been included in the present and retired: QP-007 Analiză Generală and QP-008 Analiză Detaliată

2.1 18.09.2014 Revision – templates, update references to CMMI requirements

2.2 11.11.2014Added Acceptance Test Plan update activity. Included Identify Alternative Solutions and Decide activity in the flow. Added Product Backlog (updated) output.

2.3 13.02.2015 Minor wording changes made to 3.1.6.3 and 3.1.6.5

Document History:

Author’s Name Author’s Job Title Revisions

Florin Hoinărescu General Manager v1.0, v1.2

Cristian Stelejan Quality Manager v1.1

Nicoleta Biștea Quality Audit Coordinator v1.3

Ana Maria Ghenovici Business Practice Manager v2.0

Cristina GheorghiuAnalysis & Implementation Team Leader

v2.0, v2.1, v2.2, v2.3

Document Approval

Name Job Title Date

Initiated by: Cristina GheorghiuAnalysis & Implementation Team Leader

13-Feb-2015

237

2/37


Reviewed by: Nona Gorgos Quality Audit Coordinator 13-Feb-2015

Validated by: Ioana Manas Quality Assurance & Control Manager 13-Feb-2015

Approved by: Bogdan Padiu CEO Teamnet 13-Feb-2015

Disclaimer & Copyright

Recipients of this document are aware that a physical copy may not be the latest available version. The latest version, which replaces all previous versions, is available on QMS website. The intended recipients to whom the procedure addresses are required to verify and comply with the latest version and requirements of this procedure.

This Document is the property of Teamnet and may contain confidential or privileged information. Any use of the document, unauthorized by the official Teamnet representative, eliminates any responsibility of Teamnet for any damage caused. Person using the hereunder document without authorization, may be held liable in accordance with applicable law. Teamnet reserves the right to sue any third party using the document without authorization.

337

3/37

http://dept:600/QualityPlatform/SitePages/Home.aspx


Content:

_Toc398819777

1. Policy..................................................................................................................................................... 6

2. Introduction........................................................................................................................................... 6

2.1 Purpose........................................................................................................................................ 6

2.2 Scope........................................................................................................................................... 6

2.3 Terms, Definitions and Acronyms.................................................................................................6

2.3.1 Terms and Definitions...............................................................................................................6

2.3.2 Acronyms.................................................................................................................................. 7

2.4 References................................................................................................................................... 8

2.4.1 Procedures............................................................................................................................... 8

2.4.2 Standards................................................................................................................................. 8

2.4.3 Applicable Laws........................................................................................................................ 8

2.5 Roles and Responsibilities............................................................................................................9

2.6 Process Stakeholders.................................................................................................................10

3. Process Description............................................................................................................................ 10

3.1 Process Diagram .................................................................................................................... 11

3.1.1 Establish Business Analysis Context......................................................................................13

3.1.1.1 Study project context (RD SP 1.1)..................................................................................13

3.1.1.2 Internal kickoff (RD SP 1.2, REQM SP 1.2)....................................................................14

3.1.1.3 Solution external kickoff (RD SP 1.2, REQM SP 1.2).....................................................14

3.1.1.4 Analyze stakeholders (RD SP 1.2)..................................................................................16

3.1.2 Plan Requirement Analysis and Design Work........................................................................17

3.1.2.1 Tailoring deliverable templates.......................................................................................17

3.1.2.2 Establish business analysis tools....................................................................................18

3.1.2.3 Establish development tools...........................................................................................18

3.1.2.4 Identify and estimate analysis and development activities..............................................19

3.1.3 Elicit requirements (RD SP 1.1, REQM SP 1.1)......................................................................19

3.1.4 Identify alternative solutions and decide (TS SP 1.1, SP 1.2).................................................21

3.1.5 Update and refine Requirements Matrix (RD SP 1.2, REQM SP 1.1).....................................21

3.1.6 Analyze and design requirements...........................................................................................21

3.1.6.1 Analyze AS-IS system (RD SP 2.1, TS SP 1.1)..............................................................21

3.1.6.2 Define business processes (RD SP 2.1, RD SP 2.2, RD SP 3.2)...................................22

3.1.6.3 Define architecture overview (TS SP 2.1, TS SP 2.2, TS SP 2.4)...................................23

3.1.6.4 Detailed functional design (RD SP 2.2, RD SP 2.3, RD SP 3.1, TS SP 2.3)...................23

3.1.6.5 System design (RD SP 2.3)............................................................................................24

3.1.7 Update Requirements Matrix (REQM SP 1.4)........................................................................25

3.1.8 Internal requirements validation (RD SP 3.3, RD SP 3.4).......................................................26

437

4/37


3.1.9 Validate requirements with the customer (RD SP 3.5)............................................................28

3.1.10 Review plan (REQM SP 1.5)..............................................................................................29

3.1.11 Identify Change Request (REQM SP 1.3)...........................................................................29

3.1.12 Identify Risk........................................................................................................................ 29

3.2 Interfaces with Other Processes.................................................................................................30

3.3 Resources................................................................................................................................... 31

3.4 Responsibility Matrix – RACI......................................................................................................32

4. Training for the Process...................................................................................................................... 35

5. Monitoring and Controlling the Process...............................................................................................35

6. Process Improvements........................................................................................................................ 35

7. Records............................................................................................................................................... 36

8. Measurements..................................................................................................................................... 36

9. Evaluate the Process.......................................................................................................................... 37

10. Process / Procedure Tailoring Guidelines...........................................................................................37

537

5/37


1. Policy

The Project Manager is responsible for enforcing this policy.

The Project Manager shall make sure that at least one kickoff meeting is held with the customer.

The Technical Project Manager shall make sure that the tailored templates are agreed with the Customer.

The Project Manager shall make sure that all customer requirements are documented and traced to the solution components (functional and non-functional).

Any meeting with the Customer, as well as with the internal team or partners shall be ended up with a meeting minute.

2. Introduction

2.1 Purpose

Standards Mapping: The purpose of Requirements Analysis and Design (RAD) is to elicit, analyze, and establish customer, product, and product component requirements.

2.2 Scope

The Requirements Analysis and Design process is applicable in every project executed by TeamNet, throughout the whole project lifecycle and for all the employees that execute activities which are part of the software development implementation.

2.3 Terms, Definitions and Acronyms

Besides the definition and acronyms described below, there will be applicable the terms, definitions and acronyms described in QS-002 Terms, Definitions and Acronyms.

2.3.1 Terms and Definitions

Requirement: A demand, necessity, need, constraint or parameter that must be met or satisfied. A condition or capability needed by a stakeholder to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a product or product component to satisfy a contract, standard, specification, or other formally imposed documents. A documented representation of a condition or capability as previously defined.

It may be categorized into:

- Business requirements;637

6/37

Standard Chapters

CMMI-DEV v1.3 GP 2.1

ISO 9001:2008 4.1, 4.2.1, 5.3


- User requirements;- Product/component requirement;- Project requirement.

Project requirement: A contractual provision, commitment, condition, and term that affect how products or services are to be acquired. Examples include data rights for delivered commercial off-the-shelf (COTS) non-developmental items (NDIs), delivery dates, and milestones with exit criteria. Other nontechnical requirements include training requirements, site requirements, and deployment schedules.

Business requirement: A high level business rationale that, when addressed, will allow the organization to increase revenue, avoid costs, improve service, or meet regulatory requirements.

User requirement (stakeholder requirement): Statement of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Stakeholder requirements serve as a bridge between business requirements and the various categories of product requirements.

Product requirement: A condition or capability that must be met or possessed by a product or product component to satisfy a contract, standard, specification, or other formally imposed documents. Properties (attributes) of products or services to be acquired or developed that meet the business and user requirements. A documented representation of a condition or capability as previously defined.May be categorized into:

- functional and non-functional requirements

- software and infrastructure requirements

Functional requirement: The product capabilities, functions and sub-functions organized hierarchically, their internal and external (external to the aggregation itself) functional interfaces. Functional requirements capture and describe specific intended behavior of the system being developed. They define things such as system calculations, data manipulation and processing, user interface and interaction with the application, and other specific functionalities that show how user requirements are satisfied.

Non-functional requirement: The quality attributes, design and implementation constraints, and external interfaces that the product must have.

2.3.2 Acronyms

RAD – Requirements Analysis and Design

BA - Business Analysis

BATL – Business Analyst Team Leader (Analysis & Implementation Team Leader)

SAG – Solution Architecture Group

PM – Project Manager

TPM – Technical Project Manager

ITPM – Infrastructure Technical Project Manager

737

7/37


2.4 References

2.4.1 Procedures

Nr.

Procedure Type Description/Source

IN

IN

IN

IN/OUT

2.4.2 Standards

Standards Description/Source

ISO 9001 Quality Management Standard

ISO 14001 Environmental Management Standard

OHSAS 18001 Occupational, Health and Safety Management Standard

SA8000 Social Accountability Standard

ISO 27001 Information Security Management Standard

ISO 20000 IT Service Management Standard

ISO 22301 Business Continuity Standard

CMMI-DEV v1.3 CMMI-DEV v1.3 Standard

2.4.3 Applicable Laws

Nr. Law Description/Source

837

8/37

http://dept:600/QualityPlatform/QMS/Standards%20%20Guides/Forms/AllItems.aspx?RootFolder=%2FQualityPlatform%2FQMS%2FStandards%20%20Guides%2FCMMI%20(Capability%20Maturity%20Model%20Integration)&FolderCTID=0x01200000F292B7B53CC947A47B83255AAAB547&View=%7B420D3245-F43F-4E47-B1F7-0B162108830B%7D

http://dept:600/QualityPlatform/QMS/Standards%20%20Guides/Forms/AllItems.aspx?RootFolder=%2FQualityPlatform%2FQMS%2FStandards%20%20Guides%2FISO%2022301%20(Business%20Continuity)&FolderCTID=0x01200000F292B7B53CC947A47B83255AAAB547&View=%7B420D3245-F43F-4E47-B1F7-0B162108830B%7D

http://dept:600/QualityPlatform/QMS/Standards%20%20Guides/Forms/AllItems.aspx?RootFolder=%2FQualityPlatform%2FQMS%2FStandards%20%20Guides%2FISO%2020000%20(Service%20Management)&FolderCTID=0x01200000F292B7B53CC947A47B83255AAAB547&View=%7B420D3245-F43F-4E47-B1F7-0B162108830B%7D

http://dept:600/QualityPlatform/QMS/Standards%20%20Guides/Forms/AllItems.aspx?RootFolder=%2FQualityPlatform%2FQMS%2FStandards%20%20Guides%2FISO%2027001%20(Information%20Security)&FolderCTID=0x01200000F292B7B53CC947A47B83255AAAB547&View=%7B420D3245-F43F-4E47-B1F7-0B162108830B%7D

http://dept:600/QualityPlatform/QMS/Standards%20%20Guides/Forms/AllItems.aspx?RootFolder=%2FQualityPlatform%2FQMS%2FStandards%20%20Guides%2FSA8000%20(Social%20Responsibility)&FolderCTID=0x01200000F292B7B53CC947A47B83255AAAB547&View=%7B420D3245-F43F-4E47-B1F7-0B162108830B%7D

http://dept:600/QualityPlatform/QMS/Standards%20%20Guides/Forms/AllItems.aspx?RootFolder=%2FQualityPlatform%2FQMS%2FStandards%20%20Guides%2FOHSAS%2018001%20(Health%20and%20Safety)&FolderCTID=0x01200000F292B7B53CC947A47B83255AAAB547&View=%7B420D3245-F43F-4E47-B1F7-0B162108830B%7D

http://dept:600/QualityPlatform/QMS/Standards%20%20Guides/Forms/AllItems.aspx?RootFolder=%2FQualityPlatform%2FQMS%2FStandards%20%20Guides%2FISO%2014001%20(Environmental%20Protection)&FolderCTID=0x01200000F292B7B53CC947A47B83255AAAB547&View=%7B420D3245-F43F-4E47-B1F7-0B162108830B%7D

http://dept:600/QualityPlatform/QMS/Standards%20%20Guides/Forms/AllItems.aspx?RootFolder=%2FQualityPlatform%2FQMS%2FStandards%20%20Guides%2FISO%209001%20(Quality)&FolderCTID=0x01200000F292B7B53CC947A47B83255AAAB547&View=%7B420D3245-F43F-4E47-B1F7-0B162108830B%7D


2.5 Roles and Responsibilities

Standards Mapping:

No. Role Title Functions Description

1.Project Manager (PM)

Leading role for the project assigned by the management of the company.

The PM is accountable for studying the project context, identify stakeholders from the Customer, organize and participate to external kickoff meetings.

2.Technical Project Manager (TPM)

Technical Project Manager responsible for the implementation of the solution.

The TPM is responsible for studying the project context, identify stakeholders, organize internal kickoff meetings and participate to external kickoff meetings.

3.Infrastructure Technical Project Manager (ITPM)

Manager responsible for the implementation of the infrastructure solution.

The ITPM is responsible for studying the project context, interface with the stakeholders, organizes the management of the project on the infrastructure side.

4.Business Analyst Team Leader (BATL)

Assigned by the Business Group Manager.

The BATL organizes and performs BA activities, maintains the relationship with the TPM, SAG and Customer team,

5.Business Analyst (BA)


The BA performs requirements elicitation and modeling activities and documents the results.

6.Solution Architecture Group


Solution Architecture Group is made up the following roles:Solution Architect (SA) – he has the overview of the solution from the business and technical perspective.Software Architect (SWA) – he is in charge with defining the software architectureInfrastructure Solution Architect (ISA) – he is in charge with defining the hardware architecture.

7. Test Manager (TM)

The TM takes part to the kick off meetings to facilitate the validation of the solution from the early stages of the solution development.

937

9/37

Standard Chapters

CMMI-DEV v1.3 GP 2.2, GP 2.4

ISO 9001:2008


2.6 Process Stakeholders

Standards Mapping:

No. Role Responsibilities Authorities

1. Senior ManagementProvides guidance and collects status information.

2. CustomerProvides information and feedback.Gives acceptance on the developed solution.

3. Process Description

Standards Mapping: Requirements Development focuses on covering the scope of the project, by eliciting, analyzing and modeling requirements so that the solution of the project is implemented.

Requirements Development involves:

• Analyzing the tender dossier and identifying requirements;

• Creating the Requirement analysis and design work plan, to ensure the requirements are identified and analyzed within the proper framework;

• Gather requirements from different stakeholders and sources;

• Analyze and model requirements so that each stakeholder have a clear understanding of the expected solution;

• Create the infrastructure architecture, such as all infrastructure requirements are identified, analyzed and documented;

• Validate the final solution against the initial objectives of the project.

1037

10/37

Standard Chapters


ISO 9001:2008 5.1, 5.5.1

Standard Chapters


ISO 9001:2008 5.4.2, 7.1, 7.2.1, 7.3.1


3.1 Process Diagram

Requirements Analysis and Design

Establish BA context

Identify risk

Plan Requirement

Analysis & Design Work

Analyze &design requirements

Update requirements

matrix

Inconsistencies found

Validate requirements with

the customer

Review plan

Validation ok

No new iteration

issue

Risk

Requirements matrix

[updated]

update

Peer Review Report Signed off requirements

issue

Comments received ORNew iteration start

Elicit requirements

Meeting agenda Meeting minute

Identify change request

Change request

issue

Tender documentation Product backlogTechnical Project

Identify alternative

solutions and decide

Call Peer Review

issue

Internal requirements

validation

Decision

BG Manager assigns BA TL

Call DAR

1137

11/37


1237

12/37


3.1.1 Establish Business Analysis Context

3.1.1.1 Study project context (RD SP 1.1)

Input:

Tender documentation

Output:

Internal kick off meeting minute [agenda] (see template QA-003 Meeting Minutes)

Description:

BA, BATL, SAG, ITPM, TPM and PM study the input documents in order to learn the project context and get an overview of the project in order to define agenda for the internal kick off.

Possible topics for the internal kick off agenda:

- Constraints;

- Assumptions;

- Milestones;

- Deliverables;

- Solution scope;

1337

13/37


- Project approach;

- Subcontractors.

Key aspects should be followed:- Constraints: time, already existing software and hardware solutions, geographic (the client

premises), the project team location, external applicable standards, legislation- Assumptions

- Milestones

- How clear is the scope

- Risks

3.1.1.2 Internal kickoff (RD SP 1.2, REQM SP 1.2)

Input:

Internal Kickoff meeting minute [agenda]

Output:

Internal Kickoff Meeting Minute (see template QA-003 Meeting Minutes)

Description:

The TPM organizes an internal kickoff meeting.

BATL, SAG, ITPM, TPM, TM, PM and other interested persons invited by PM meet at the beginning of the project in order to establish the internal strategy for the project implementation.

During the meeting, the participants share information about the project and the client. Each topic in the agenda is addressed and discussed, and the commonly agreed aspects are written into the meeting agenda.

Any identified risk is recorded in the meeting minute and it is reported to PM/TPM to be followed up in the risk register.

By the end of the meeting everyone should know:- the sponsor’s implementation decisions;

- the milestones and how to prepare for them, particularly for the first ones in the project;

- the framework where to organize its WBS components;

- the split of work with the partners or subcontractors;

- risks etc.For example, after the meeting, the BATL should have enough information to start organizing the business analysis domains, taking into account time, solution scope and subcontractors/partners’ part.The internal kickoff meeting can be performed in one or multiple sessions, depending on the project need.

3.1.1.3 Solution external kickoff (RD SP 1.2, REQM SP 1.2)

Input:

1437

14/37


Tender documentation Internal Kickoff Meeting Minute (see template QA-003 Meeting Minutes)

Output:

Solution Kickoff Presentation Signed solution external kickoff meeting minute (see template QA-003 Meeting Minutes)

Description:

The BATL, TPM, ITPM and SAG prepare the kickoff presentation for the meeting with the Customer.

The PM organizes a technical kickoff meeting with the customer’s technical representatives.

BATL, TPM and SAG participate to the meeting and present to the customer how the project will be run in order to accomplish the project.

The main objectives of the solution external kickoff are:

- Present the supplier’s technical team to the customer team;

- Present the main phases of the project and briefly explain what steps includes each of them;

- Present the expectations of the supplier team from the customer team (in terms of facilitation, openness, team organization, availability etc).

By the end of the meeting, the BATL, TPM and SAG must make sure that the Customer team understands and agrees with the presented approach. If the Customer cannot validate the approach in a single session, the PM should organize another validation session or the Customer should agree with a date when he sends the answer.

The meeting will be held once at the beginning of the project. If the customer team changes more than 50% or after 6 or more months since the project start, the TPM will decide whether it is necessary to redo this meeting.

Possible solution kickoff presentation topics:1. The main phases for solution development

a. Analysis and Designb. Developmentc. Testingd. System installation (part of Product Integration)e. Implementation (configuration, training, go live)f. How is each phase accepted

2. Main areas of interest for analysis and designa. Meetings with the customer for analysis and design (meeting agenda, meeting participants,

meeting minutes)b. Meetings to validate the requirementsc. Meetings to validate the solutiond. Deliverables

i. Scope, structureii. When and who will sign them

1537

15/37


The main deliverable template is the Technical Project Documentation.e. Tender book as the base for the solution scopef. What is a change request

3. Developmenta. The solution will be developed at the supplier’s office. There might be exceptions from this

rule, if the contract enforces otherwise (i.e. from confidentiality reasons).b. Intermediary releases will be presented to the customer at previously agreed dates for

validation and feedback.4. Testing

a. Internal testingb. Customer testing (for feedback and for acceptance)c. Acceptance report – what it is and why it is necessary

5. Expectationsa. Client from supplier

i. To be explained what happens in the projectii. To build a system that covers their requirements

b. Supplier from customeri. To participate to the project meetingsii. To participate to the testing sessionsiii. To obtain consensus with the colleagues on debatable topics.

6. Meet the teams

3.1.1.4 Analyze stakeholders (RD SP 1.2)

Input:

Stakeholders

Output:

Stakeholders [updated]

Description:

The PM sends to TPM and ITPM the external stakeholders list that he identified so far. The TPM and ITPM share the information with the BATL and SAG.

BATL, TPM, ITPM and SAG analyze the external stakeholders list and search the needed profiles from various perspectives to ensure that all required persons and interests are identified in order to develop appropriate approach techniques.

The perspectives are:

- technical background;

- business knowledge;

- manager vs. operative;

- internal or external participant;

- Human or system participant.

1637

16/37


If TPM, ITPM, BATL and SAG cannot find the needed profiles, they request the PM to request them from the Customer team and include them into the stakeholder list.

Approach techniques will be developed later in the project, such as:- for an operative person not having technical background, textual descriptions will be preferred

and technical arguments will be avoided, with focus on results- a technical person can understand technical issues with less explanation

- managers are invited to meetings separated from their operative personnel in order to avoid blind subordination while explaining how work is done

- external systems need dedicated attention

3.1.2 Plan Requirement Analysis and Design Work

3.1.2.1 Tailoring deliverable templates

Input:

Tender Documentation

Output:

Tailored Technical Project Template (see template QA-169 Technical Project) Signed Meeting Minute (see template QA-003 Meeting Minutes) Tailored Acceptance Test Plan (see template QA-207 Acceptance Test Plan)

Description:

BATL and SAG adjust the Technical Project template in order to accommodate the tender documentation.

The adjustments should focus on the following elements:

- Aspects that are required in the tender documentation or by the contracting partner and are not already included in the Technical Project template;

- Form;

- Structure;

- Naming conventions for the document throughout the solution development.

Examples of required aspects in the tender book:- impact analysis for a group of stakeholders,

- information be provided in a required format.Form : header, footer, personalized visual identity elementsNaming conventions: the tender documentation or initial project plan may impose splitting the Technical Project into multiple documents or renaming them.

1737

17/37


The BATL, SAG and TL Testing adjust the Acceptance Test Plan template and establish the approach of how acceptance tests will be described in order to accommodate the tender documentation. The tests descriptions’ approach will be included in the Acceptance Test Plan template for the project.

Examples of required aspects in the tender book:- information be provided in a required format.

Form : header, footer, personalized visual identity elementsNaming conventions: the tender documentation or initial project plan may impose splitting the Acceptance Test Plan into multiple documents or renaming them.

The Technical Project Manager ensures that the templates are agreed with the Customer representatives.

3.1.2.2 Establish business analysis tools

Input:

Standard work environment

Output:

Tool catalogue [List of business analysis tools]

Description:

The BATL chooses the appropriate list of tools that will support the business analysis activities. The tools should cover the following:

- requirements management: attributes, traceability;

- requirements design: process modeling, data modeling, interface design;

- user interface design: mockup screens.

3.1.2.3 Establish development tools

Input:

Standard work environment

Output:

Tool catalogue [List of development tools]

Description:

SAG chooses the appropriate tools that will be used by the developers. This includes the source code editor/IDE, build automation environment, web server and database management system.

These are the tools that will be used by the development team during development, and not necessarily the same versions that will be used in production. For example, one can decide to use IIS Express for development but deploy on IIS.

1837

18/37


3.1.2.4 Identify and estimate analysis and development activities

Input:

Tender documentation Project Management Plan (WBS)

Output:

Product backlog [initial]

Description:

TPM establishes the product backlog structure.

BATL, SWA (and/or software development team leader) identify the list of activities that will be performed for analysis and development. The identified activities are high-level in the beginning of the project and they will be refined at TPM request and with the progress of increments.

After activity identification, BATL and SWA estimate the necessary effort for each work item and create the initial product backlog.

ITPM and ISA will estimate all activities related to the development of the architecture for the hardware infrastructure and all related aspects. All the identified activities will initially be high-level, and will be defined with further increments of the procedure. After the identification, they will estimate the effort of each item and will add it to the initial product backlog.

3.1.3 Elicit requirements (RD SP 1.1, REQM SP 1.1)

Input:

Tender documentation Stakeholders

Output:

Signed Meeting minute (see template QA-003 Meeting Minutes)

Description:

BA, BATL, SAG elicit requirements from stakeholders in order to identify the solution requirements.

The requirements elicitation activity can be performed using various techniques:

- Document analysis;

- Interface analysis;

- Interviews;

- Observation;

- Prototyping;1937

19/37


- Requirements workshops;

- Survey/Questionnaire;

- Brainstorming;

- Focus groups.

The following stages should be observed when performing the requirements elicitation activity:

- Prepare for elicitation: BA, BATL or SAG ensure that the elicitation activity is organized and scheduled. BA, BATL or SAG must specify the activity objectives (for example: meeting agenda for an Interview, focus subjects for Document Analysis or Interface analysis) and when the activity will take place.

- Conduct elicitation activity: BA, BATL or SAG perform the elicitation activity either by meeting with the stakeholders to elicit requirements regarding their needs or to clarify the requirements stated in the tender documentation or by going through applicable laws or standards.

- Document elicitation results: BA, BATL or SAG record the information provided by stakeholders to use in the analysis process. The results are documented in the form of meeting minutes (if meetings with the stakeholders were held) and/or stated requirements in the Requirements Matrix.

- Confirm elicitation results: BA, BATL or SAG validate that the stated requirements match the stakeholder understands of the problem and the stakeholder’s needs. The results are signed meeting minutes.

The meeting minute should be stored on the project repository.The naming convention for the meeting minutes should be: yyyy_mm_dd_Topic

The requirements elicitation process can end up with a signed meeting minute depending on the selected technique (such as: Requirements workshops, Interviews, Prototyping), or it can only gather information from various sources (such as: Observation, Document Analysis, Survey).

2037

20/37


3.1.4 Identify alternative solutions and decide (TS SP 1.1, SP 1.2)

Input:

Tender documentation Signed Meeting Minutes (see template QA-003 Meeting Minutes)

Output:

Decision (see template QA-085 Decision)

Description:

Throughout the project lifecycle the BA, BATL and SAG should identify various possibilities to define the proposed solution, both from technical and business perspective. They should consider alternative solutions and decision criteria for, at least, the following topics:

- COTS versus custom-made solutions;

- Different technologies.

BA, BATL and/or SAG record the decision in the decision log of the project.

The decision log contains the alternative solutions, evaluation criteria, decided solution and the team members who made the decision.

3.1.5 Update and refine Requirements Matrix (RD SP 1.2, REQM SP 1.1)

Input:

Requirements Matrix [TD X Owner] (see template QA-197 Requirements Matrix) Requirements matrix [TD X TO] (see template QA-197 Requirements Matrix)

Output:

Requirements Matrix [User Requirements] (see template QA-197 Requirements Matrix)

Description:

BA, BATL and SAG update the Requirements Matrix with the information obtained during the requirements elicitation activity.

The requirements stated in the tender documentation are clarified so that acceptance criteria for the solution can be developed.

After the elicitation activity, the requirements attributes may be changed, for example: state, owner aso.Also, the initial requirements may be vague, so a more clear understanding can be given.

2137

21/37


3.1.6 Analyze and design requirements

3.1.6.1 Analyze AS-IS system (RD SP 2.1, TS SP 1.1)

Input:

Tender documentation Signed Meeting minutes (see template QA-003 Meeting Minutes)

Output:

Technical Project [Chapter 4 Existing System Analysis] (see template QA-169 Technical Project)

Description:

BA, BATL and SAG identify the existing framework and infrastructure in which the future solution should fit. The AS-IS analysis should focus on the following existing items:

- Position of the client’s organization in a larger context (for example: the client’s organization is member of a group of organizations having the same objectives on a dedicated topic);

- organizational structure that will be impacted by the solution development or infrastructure changes;

- legacy systems and legacy infrastructure;

- legislation and regulations in force that will impact the future solution;

- business actors and business domain.

The AS-IS analysis should be performed in more detail if the existing system is more complex and is subject to change consistently.If the changes to the current system are isolated/limited, the as-is analysis can be targeted only to the changed aspects.

3.1.6.2 Define business processes (RD SP 2.1, RD SP 2.2, RD SP 3.2)

Input:

Tender documentation Requirements Matrix [UReq] (see template QA-197 Requirements Matrix) Signed meeting minutes (see template QA-003 Meeting Minutes) Peer Review Report [available starting with the second iteration] (see template QA-253 Peer

Review Report)

Output:

Technical Project [Chapter 5.1 Business Processes] (see template QA-169 Technical Project)

Description:

BA and BATL identify the future business and support processes in order to understand and prove how the future system will work in the client’s organization.

2237

22/37


The business and support processes show how actors interact and what activities they perform, with or without the proposed solution, stating clearly what will be supported by the future solution and what will be performed manually or by another system/solution.

After validation [Signed off requirements] and verification [Peer Review Report] of the high-level functional architecture, the BA and BATL will implement the comments, so that a more clear understanding is made for the high-level solution. The comments will be implemented in the next iteration of the project.

While identifying business and support processes, the BA and BATL must specify the logical interfaces between the proposed solution and other systems.

Business actors are humans (identified by organizational structures, positions or functions) or other systems that perform activities that are relevant to the proposed solution.Business processes are the interactions between actors that help them to achieve a specific business objective.Support processes are those interactions that ensure that business processes can be performed consistently.Business and support processes must ensure coverage for the high-level functional requirements.

3.1.6.3 Define architecture overview (TS SP 2.1, TS SP 2.2, TS SP 2.4)

Input:

Tender documentation Peer Review Report [available starting with the second iteration] (see template QA-253 Peer

Review Report) Requirements Matrix [UReq] (see template QA-197 Requirements Matrix) Signed meeting minutes (see template QA-003 Meeting Minutes)

Output:

Technical Project [Chapter 5.2 Architecture Overview] (see template QA-169 Technical Project)

Description:

SAG specifies the high-level architecture to ensure that all technical aspects of the solution are analyzed and covered.

The high-level architecture should focus on the following topics:

- Software component architecture;

- Hardware (including storage) architecture;

- Network architecture;

- COTS software products architecture;

- Security architecture;

- Interface architecture.

SA aggregates all views (software, hardware, business) of high-level architecture and ensures that all ends meet, that there is no gap between them.

2337

23/37


After validation and verification of the high-level architecture, the SAG will implement the comments, so that a more clear understanding is made for the high-level solution.

3.1.6.4 Detailed functional design (RD SP 2.2, RD SP 2.3, RD SP 3.1, TS SP 2.3)

Input:

Technical project (see template QA-169 Technical Project) Signed meeting minutes (see template QA-003 Meeting Minutes) Requirements Matrix [UReq] (see template QA-197 Requirements Matrix) Peer Review Report [available starting with the second iteration] (see template QA-253 Peer

Review Report)

Output:

Technical Project [Chapter 6. Detailed Functional Design] (see template QA-169 Technical Project)

Acceptance Test Plan [Chapter 5.2.5 Functional tests, Chapter 5.2.6 Integration tests] (see template QA-207 Acceptance Test Plan)

Description:

BA and BATL define the detailed functional specifications for the future solution. The detailed specifications must map both business and support processes and functional requirements, as they are stated into the Requirements Matrix, to ensure coverage of the solution scope.

The functional detailed specifications should concentrate on the following topics:

- System functional detailed specifications;

- Statistics and lists (reports) specifications;

- Interface specifications;

- System roles;

- GUI mockups, optional;

- Data model, optional.

The Tester creates the Acceptance Test Plan based on the Acceptance Test Plan template and approach agreed in the Tailoring deliverable templates activity.

3.1.6.5 System design (RD SP 2.3)

Input:

Technical project [high-level architecture] (see template QA-169 Technical Project) Signed meeting minutes (see template QA-003 Meeting Minutes)

2437

24/37

System functional detailed specifications can be presented in the form of user stories, use cases or functional specifications.See the Technical project template.


Requirements Matrix [UReq] (see template QA-197 Requirements Matrix) Peer Review Report [available starting with the second iteration] (see template QA-253 Peer

Review Report)

Output:

Technical Project [Chapter 7. Technical Architecture of the Informatics System] (see template QA-169 Technical Project)

Acceptance Test Plan [Chapter 5.2.7 Non-functional tests] (see template QA-207 Acceptance Test Plan)

Description:

SAG defines the detailed specifications for the future system. The detailed specifications must map the non-functional requirements, as they are stated into the Requirements Matrix, to ensure coverage of the solution scope.

The non-functional detailed specifications should focus on the following topics:

- Software component architecture;

- Hardware (including storage) architecture;

- Network architecture;

- COTS software products architecture;

- Security architecture;

- Interface architecture;

- Management and monitoring.

SAG aggregates all system design views and ensures that the overall architecture is respected.

The Tester creates the Acceptance Test Plan based on the Acceptance Test Plan template and approach agreed in the Tailoring deliverable templates activity.

3.1.7 Update Requirements Matrix (REQM SP 1.4)

Input:

Requirements Matrix [UReq] (see template QA-197 Requirements Matrix) Signed Meeting Minute (see template QA-003 Meeting Minutes)

Output:

Requirements Matrix [UReq X PReq] (see template QA-197 Requirements Matrix) Requirements Matrix [Req X TC] (see template QA-197 Requirements Matrix)

Description:

BA, BATL and SAG map the developed analysis work items to the stated requirements to ensure full coverage of the solution scope.

2537

25/37


The requirements matrix should show coverage between both functional and non-functional requirements.

Functional requirements should cover the following trace path: solution requirements from the tender documentation and solution requirements from meeting minutes or other official communication means mapped to high-level specifications, which are mapped to low-level specifications, which are traced to test cases.

Non-functional requirements should cover the following trace path: solution requirements from the tender documentation and solution requirements from meeting minutes or other official communication means mapped to architecture specifications (chapters) and test cases

3.1.8 Internal requirements validation (RD SP 3.3, RD SP 3.4)

Input:

Technical Project (see template QA-169 Technical Project) Product backlog Requirements Matrix (see template QA-197 Requirements Matrix)

Output:

Peer Review Report (see template QA-253 Peer Review Report) Product backlog [updated] Technical Project [updated]

Description:

TPM and ITPM, after consulting BATL and SAG, will establish how the internal validation of requirements will be addressed, what types of reviews will be conducted, what work product to select, what reviewers others than team members will participate.

The following review types will be considered:

a) Validation of the functional requirements by SAG (mandatory)b) Review of functional requirements by BATL (mandatory)c) Cross review of functional requirements (optional)d) Validation of system design (optional)

When deciding what types of review will be conducted and what work product to be selected, the following criteria will be considered, but not limited to:

- Number of team members with appropriate expertise

- Time schedule

- Complexity of requirements and degree of risk of the proposed solution

Validation of the functional requirements by SAG

BA presents to the SAG the elicited requirements and the functional design proposal so that the SAG can learn and analyze the validity of the solution.

2637

26/37


The validation process should be focused on the following topics:

- The functional specifications are clearly and properly stated;

- The functional specifications can be implemented on the designed architecture;

- The functional specifications do not have gaps in terms of implementation details, are necessary and sufficient.

The reviewers perform their tasks, highlight and/or modify the documentation accordingly. If needed, they discuss the identified inconsistencies with the author. The Moderator aggregates the findings in a Peer Review Report and mark the work product as compliant or not compliant.

In case the review reveals that the deliverables are not compliant, the BATL updates the Product Backlog in order to take into account the time needed for the required modifications/updates.

The reviewers can modify directly the work items leaving change marks, depending on the tool that it is used. The changes that are applied directly to the documentation can be of the following types: spell checks, typos, rephrase the statement to make it clearer, add small pieces of information to complete integration between models, any changes that are discussed and agreed with the author of the work item.The Peer Review Report should contain at least a summary of the identified comments or changes.The Peer Review Report can be attached to the associated backlog work item.

Review of functional requirement by BATL

BATL checks the elicited requirements and the functional design proposal of the business analyst in order to ensure an integrated view of the requirements and compliance with the approach established for the business analysis activities. This should be done during defining business processes or the detailed functional design, to prevent unnecessary rework and to ensure the entire team follows the same guidelines.

The validation process should be focused on the following topics:

- The functional specifications are stated in the established format and level of detail is necessary and sufficient;

- The functional specifications are traceable to the user requirement;

- The functional specifications are clearly and properly stated and consistent.

The BATL discusses the identified inconsistencies with the authors and aggregates the findings in a Peer Review Report.

The internal requirements validation activity will be organized as a tailored Peer Review Process:

Review type Validation of the functional requirements by SAG

Review of functional requirement by BATL

Cross review of functional requirement

Validation of system design

Scope of peer review

The peer review is performed by the project team in order

The peer review is performed by the BATL in order to

The peer review is performed by business analysis

The peer review is performed by members of the SAG

2737

27/37


to ensure a consistent view of the requirements across functional design and system design.

ensure compliance to the approach adopted for the technical project.

team in order to validate the functional design.

in order to validate the system design.

Set the roles and responsibilities

BATL is the Initiator, TPM is Moderator.Selected member(s) of SAG are Reviewers.

BATL is Initiator, Moderator and Reviewer.

The BATL is the Initiator and Moderator.Business Analysts are Reviewers.

Roles and responsibilities will be established by TPM/ITPM.

Work products to be reviewed

Selected requirements from Technical Project

Selected requirements from Technical Project and Requirements matrix

Selected requirements from Technical Project

Selected requirements from Technical Project and Requirements matrix

Review criteria Functional specification are:

- Clearly and properly stated

- Appropriate to implement

- Complete, necessary and sufficient

The criteria includes but are not limited to:

- Compliance with format

- Compliant with level of details for the description

- Traceable

- Consistency

- Language

The criteria includes but are not limited to:

- Compliance with format

- Compliant with level of details for the description

- Completeness

- Content

- Consistency

- Language

The criteria are established before the validation starts.

Based on the findings from the Peer Review the BATL or SAG may decide to update the Product backlog and the Technical Project, depending on the identified issues.

2837

28/37

The reviewers should not be the authors of the selected work item to be reviewed.

All the above roles are part of the project, not outside it.

If there is no member other than the author with the needed competence in the team (for example, there is only one BA in the team) the Peer Review should be performed by a member of the team with the closest competence or by a member outside the team, selected by TPM/ITPM.


3.1.9 Validate requirements with the customer (RD SP 3.5)

Input:

Technical Project (see template QA-169 Technical Project)

Output:

Requirements validation Meeting Minute (see template QA-003 Meeting Minutes)

Description:

By the end of each iteration, the requirements are validated with the customer. The validation process assumes that the BA and SAG present to the customer the developed requirements and collects feedback on the understanding of the requirements and their modeling.

The requirements validation process involves, typically, the following activities:

- Validate the Requirements Matrix;

- Validate the prototypes, if any;

- Validate the business processes and functional specifications;

- Validate the constraints;

- Validate the interfaces with other systems;

- Validate the overall architecture.

The naming convention for the meeting minutes should be: yyyy_mm_dd_Topic

3.1.10 Review plan (REQM SP 1.5)

Input:

Product Backlog

Output:

Product Backlog [updated]

Description:

Taking into account the level of completion of the activities and the latest acquired information from the previous phase(s), the TPM, ITPM, BA, BATL and SAG will review the activities from the product backlog and update them if this is necessary.

3.1.11 Identify Change Request (REQM SP 1.3)

Input: N/A

Output:

Change request (see template QA-005 Change Request)

2937

29/37


Description:

Throughout the project lifecycle, the BA, BATL or SAG can identify changes requested either by the customer or by ISA development team. The change request is redirected to the appropriate team member to be documented and managed: BATL, member of SAG, PM, ITPM or TPM, as defined in the Change Management Plan.

The infrastructure changes can be forced by events such as a change of physical location, hardware

going End-Of-Life or is no longer for sale, and so on.

3.1.12 Identify Risk

Input: N/A

Output:

Risk Register (update)

Description:

Throughout the project lifecycle, if the BA, BATL or SAG identify risks that can affect the solution development redirects the information to TPM to be recorded into the Risk Register.

3.2 Interfaces with Other Processes

Peer Review Process

3037

30/37


3.3 Resources

Standards Mapping:

Standard Chapters


ISO 9001:2008 6.1, 6.2.1, 6.3, 6.4

No.

NameBackup Resource

(BCP)

Resource typeDetails/ReferencesHuman

resourceMaterial Infrastructure Other

3.4 Responsibility Matrix – RACI

Activity \ RoleBusiness Analyst

Business Analyst Team

Leader

Technical Project

Manager

Infrastructure technical

Project Manager

Project Manager

Solution Architectur

e Group

TestManager

TL Testing

Tester

Study project context

R R R R A, R R

Analyze stakeholders

I R R R A R

Internal kick off I R R R A, R R R

Solution I R R R A R

3137

31/37


external kick off

Tailoring deliverable templates

C R A R I R R

Establish BA Tools

C R A I I

Establish development tools

I I A I R

Identify and estimate analysis and development activities

C R A, R R I R

Elicit requirements

R R A I R

Identify alternative solutions and decide

R R R, A R R

Analyze AS-IS system

R R A R

Define business processes

R R A C, I

Define architecture overview

I I A R

Detailed functional design

R R A C, I R

System design I I A R R

3237

32/37


Update and refine Requirements Matrix

R R A R

Internal requirements validation

R R A R R

Validate requirements with the customer

R R A I R

Review plan C R A R I R

Identify risk R R R R A R

Identify change request

R R R R A R

Legend: <R> - Responsible; <A> - Accountable; <C> - Consulted, <I> - Informed

3337

33/37


4. Training for the Process

Standards Mapping: Describe all training needs for the process, materials and resources, who will perform the training and when.Prezentare – ownerii de process, se adreseaza celor din scop, cu referinta la procedura de training intern QP-038

5. Monitoring and Controlling the Process

Standards Mapping:

Senior Management is responsible for monitoring and controlling the process at organization level, through offering process assets and work environment.

The process is monitored through management review and status reports. The PM of the project is responsible for monitoring and controlling the process at project level, through:

- Reviews;

- Meetings;

- Analysis;

- Risk identification and evaluation;

- Identified problems and issues;

- Preventive and corrective actions.

6. Process Improvements

Standards Mapping: Mention how all improvements proposals are collected (lessons learned, experience, audits, reviews, measurements, supplier evaluation, etc.), evaluated and included in the organizational improvement plan for the

processes.Improvements can be registered in the TTPro/QA database by all employees.

3437

34/37

Standard Chapters


ISO 9001:2008 6.2.2

Standard Chapters


ISO 9001:2008 5.5.3

Standard Chapters


ISO 9001:2008 8.5.1


7. Records

Standards Mapping:

No.

Code Name Format

Process/Project

Milestone?

Retention time Repository

1. QA-003Meeting Minutes

ElectronicPaper

No*only if not specified in QMS

*only if not specified in QMS

2. QA-005Change Request

Electronic Yes

3. QA-085 DecisionElectronicPaper

Yes

4. QA-169Technical Project

Electronic Yes

5. QA-197Requirements Matrix

Electronic Yes

6. QA-211Testing Project Plan

Electronic No

7. QA-253Peer Review Report

Electronic Yes

8. QA-207Acceptance Test Plan

Electronic No

For templates used and records information, please check the Process Documentation Catalog.

8. Measurements

Standards Mapping: List the relevant KPI to measure the effectiveness of the process and the work products from process.Process measurements are monitored regularly and are under the control of the Measurements and Analysis process.

KPIs folositi in toate procesele (2 exemple)

3537

35/37

Standard Chapters


ISO 9001:2008 4.2.3, 4.2.4

Standard Chapters

CMMI-DEV v1.3

ISO 9001:20085.4.1, 8.1, 8.2.1, 8.2.3, 8.2.4

http://dept:600/QualityPlatform/QMS/_layouts/15/start.aspx#/Lists/Process%20Documentation%20Catalog/Approved%20Documents.aspx

http://tni-hq-srv-shp1/QA/Lists/Lista%20procedurilor/In%20Vigoare.aspx

http://tni-hq-srv-shp1/QA/Lists/Lista%20procedurilor/In%20Vigoare.aspx


3637

36/37


9. Evaluate the Process

Standards Mapping: Describe all evaluations applicable to the process/ procedure and the project work products (internal audit, verification, validation, reviews, KPI, corrective / preventive actions, performance evaluation, etc). Describe how the process performance is visible to higher management as an overall view (report status,

results of pilots, readiness, and milestone progress, management review reports)

10. Process / Procedure Tailoring Guidelines

Standards Mapping: Projects should tailor the process as appropriate to the size and scope of the project and its work products. Each department / project may choose which process approach to implement and the extent of tailoring applied as appropriate, to the

department / project needs. Departments / projects may also tailor the process/procedure checklists, forms, templates and other work aids to their needs.

The following table presents the tailoring for the process elements listing the attributes of each process elements that may be tailored. The table provides alternative solutions and observations to guide a project in selecting the appropriate degree of tailoring applied to the process.

No.Process Element

Tailored AttributeAlternative

SolutionObservation

Role Activity

<scope><duration><form><template><checklist><process><procedure>

3737

37/37

Standard Chapters

CMMI-DEV v1.3 GP 2.9, GP 2.10

ISO 9001:20085.6, 7.2.2, 7.3.4, 7.3.5, 7.3.6, 8.2.2, 8.3, 8.4, 8.5.2, 8.5.3

Standard Chapters


ISO 9001:2008 -

QP-006 Requirements Analysis and Design

Documents

Transcript of QP-006 Requirements Analysis and Design