EDUCATION, SYSTEM ANALYSIS, BABOK

🔍 System analysis - visual examples

The path from the idea to the verified requirement: what is involved, how the requirements are studied and arranged, how they are recorded, modeled and tracked to the test. Examples are based on this platform and simplified for training.

ISO/IEC/IEEE 12207:2017 - Life Cycle

SDLC: one sequence or short repeated cycles

The phases are the same. The difference is how many times they go out: Waterfall - once for the whole system, iteratively - in each sprint for a small part.

SDLC: Waterfall and iterative approach Top seven phases in one order. Bottom product stock and three sprints, each delivering increment, and after each has feedback. Waterfall - once, linear ProgrammingPlanning RequirementsRequirements DesignDesign DevelopmentImplementation TestingTesting ImplementationEmployment MaintenanceMaintenance Iterative (Agile, Scrum) - short sprint, each supplying part Product stock backlog, priorities Sprint 1 (2 weeks) plans - develops - tests - reviews Sprint 2 plans - develops - tests - reviews Sprint 3 plans - develops - tests - reviews 1 user increment 2 increment 3 feedback after each sprint changes stock

When

Waterfall - when requirements are stable and approved in advance (contract, regulation). Iteratively - when requirements change and the value wants to be delivered by instalments.

References

ISO/IEC/IEEE 12207:2017, ISO/IEC/IEEE 15288:2023, Scrum Guide-2020, NIST SP 800-218 (SSDF).

Safety in each phase

Safety requirements shall be written with the others, not before implementation. Iteratives - in each sprint as part of the definition of readiness. Safe development.

Mendelow (1991) - matrix of influence and interest

Who should be closely involved, who should only be informed

A matrix of stakeholders' influence and interest Four quadrants: maintain satisfied, closely involved, monitor, regularly inform, with examples of sides in each. Effect (copper) → Interest → Maintain satisfiedkeep satisfied Close involvementmanage closely Monitormonitor Regularly informkeep informed Board, financier Supervisory authority Product owner Main client General public End users Data Protection Officer The position changes during the project - the matrix review each phase.

When

Before taking action: a forgotten party means forgotten requirements. Repeat when the organisation or priorities change.

References

Mendelow A. (1991), IIBA BABOK v3 (3.2 Plan Stakeholder Engagement), PMI PMBOK 7 (2021), ISO 21502:2020.

Security Parties

The addressee of monitoring and incident reporting is defined by national legislation (acceptance of CIS2) - early warning 24 h, notice 72 h. Both authorities are listed at the start of the project.

IIBA BABOK v3 - Chapter 4, MoSCOW

How requirements are obtained, arranged and made verifiable

Knowledge, MoSCOW and user story On the left, six methods of knowledge with their strengths, among the MoSCOW priorities, the right user story with acceptance criteria. 1. Find out Interviewdepth, motives Workshoparrangements between the parties Observationreal work Questionnairemany respondents Analysis of documentsexisting provisions Prototypeconfirms understanding 2. Arrange (MoscoW) Must - Mandatorywithout it there is no point Should - Shouldimportant, but there is a bypass Couldif time remains Won't - this time norecorded, postponed intentionally 3. Recording verifiablely As a buyer, i want to filter by category, to quickly find a specialist. Acceptance criteria Givencategory includes 20 ads Whenchoose this category Thensee only its adverts and their number (20) criterion 2 = test that can be started

How to use

One method is not enough: the interview gives motives, observation - what people actually do. The must part is recommended not more than 60% of the work volume, otherwise there is no reserve.

References

IIBA BABOK v3 (chapter 4) Elicitation and Collaboration), ISO/IEC/IEEE 29148:2018, DSDM/AgilePM (MoscoW), Cohn M. (2004) User Stories Applied, INVEST.

Safety requirements

You know, like the rest, with the story "How an attacker I want..." and OWASP USAS as a checklist. Application protection is Must, not Could.

ISO/IEC/IEEE 29148:2018 - ISO/IEC 25010:2023

Four levels of requirements - from "why" to "how good"

Pyramid of requirements Business, user, functional and non-functional requirements with examples of this platform. The limits apply to all levels. Business User requirements Functional requirements Non-functional (quality) ISO/IEC 25010:2023 Why? What? What? How good? example: this platform BusinessFind a test specialist faster UserHow to seek by category FunctionalThe filter returns 20 results per page Non-functionalp95 < 300 msec, 99.9%, 2FA Restrictions - NIS2, GDPR, contracts, technology no individual level: they limit all four

How to use

Each lower-level requirement has to come from the higher one. The non-functional requirement is measurable: not "fast', but "p95 < 300 ms'.

References

ISO/IEC/IEEE 29148:2018 (replaced IEEE 830-1998), ISO/IEC 25010:2023, IIBA BABOK v3, OWASP USAS.

Safety is a quality requirement

Authentication, encryption and magazines are non-functional requirements with measurable criteria. Article 21 of the NIS2 is the limitation from which it arises.

UML 2.5.1 - misuse cases

Who uses the system - and how it could be abused

Abuse case diagram The visitor, registered user and administrator use the platform. The attacker tries to take over the account and fake the rating. Application with 2FA reduces account take-over. Platform (system boundary) Visitor Registereduser Administrator Attacker See advertisements Search by category Register Publish an advertisement Pay plan Apply with 2FA Send Message Evaluate specialist Model content Take Account Counterfeit rating "extend" a threat "share" a threat

Triangle arrow - generalization: a registered user can all by a visitor. "extend" - optional extension (free plan published without payment). Red abuse.

When

Collecting requirements: the image allows users to check that nothing is forgotten. For each case, the scenario and the acceptance criteria shall be written later.

References

OMG UML 2.5.1 (2017), Cockburn A. (2001) Writing Effective Use Casees, Sindre G., Opdahl A. L. (2005) Eliminating security requirements with misuse cases.

Abuse

Ask, "How could an attacker use it? The answer becomes a security requirement - for example, 2FA against account takeover, signed ratings and modeling against counterfeiting.

BPMN 2.0 (ISO/IEC 19510:2013)

Process with lanes: who does what and where the path branches

Example - publication of a advertisement. The lanes show who takes the step, the gateway - where the process selects one of the roads.

BPMN process: publication of the advertisement The specialist completes the advertisement, the platform checks the fields. If the plan is free, the platform shall be published immediately. Where fees are confirmed and paid by the professional, the payment gateway shall process the payment and notify the platform that publishes. Gateway Specialist Platform To be completed by advertisement Checking fields Approval and payment Processing of payment Published by Plan? fees free signature Published

Thin circle - beginning, thick circle - end, rounded rectangle - task, diamond with X - exclusive gateway (only one road).

AS-IS and TO-BE

First of all, model how the process happens now, then how it should happen. The difference between the two is the input of the difference analysis.

References

OMG BPMN 2.0.2 (2014), ISO/IEC 19510:2013, IIBA BABOK v3 (10.35 Process Modelling).

Confidence limits

Each transition between bands belonging to different organisations is the limit of credibility. There is a need for a check and a log - e.g. verification of the gateway notice signature before publication.

ISO/IEC/IEEE 29148:2018 - Trackability Matrix

Each requirement until test and control - in both directions

Traceability chain Aim, requirement, solution, test and control relate in both directions: forward - or all introduced, backward - why it is at all. Business objectiveBR-01 RequirementFR-03, NFR-07 Optionmodule 1, change TestTC-12, TC-31 ControlISO 27001 A.8.5 → forward: whether each requirement has been introduced and verified ← back: why this code or test is at all
IDRequirementSourceTestControlStatus
FR-03Filter by CategoryBR-01TC-12: only the selected category-Tested
NFR-07Application with 2FABR-02, NIS2 21 p. 2 d. j)TC-31: no code accessISO/IEC 27001 A.8.5Tested
NFR-09Statement of payment with signatureBR-03TC-40: false signature rejectedISO/IEC 27001 A.8.24Tested
FR-11Content complaintDSA p. 16.--No test - crack

What it gives

Prove that nothing is forgotten and nothing is superfluous. When changing the requirement, see immediately which tests and controls are affected.

References

ISO/IEC/IEEE 29148:2018, IIBA BABOK v3 (5.1 Traces Requirements), ISO/IEC 27001:2022 A.8.25 A.8.29.

Audit

The auditor requires precisely this chain: requirement - control - proof. The row without the test is a finding. Audit guide.

IIBA BABOK v3 - Chapter 6

Now, action, desired - each gap in your line

The desired position describes the result that can be measured. Technology is the activity that leads to it.

Analysis of differences: current, action, desired Seven rows, each current state, performance and measurable desired state. Bottom common resources. Now (AS-IS) Proceedings Preferred (TO-BE), measurable 2FA only 30% of accountsTOTP for all, admins mandatory100% admins, ≥80% users No Audit LogLog Access and ChangeJournal ≥12 months, review every month. Payments by emailPayment gateway with signaturePayment automatic, without emails Weekly copiesDaily encrypted copy off-siteRFMO ≤ 24 h, renewal checked No incident planDevelop and try a planNIS2 notification 24 h / 72 h Certificates manuallyAutomatic renewal of TLSNo expired certificates LV onlySelf-contained EN translationLV + EN, data remains with us Resources: ~3 months - 2 engineers - ~5 k EUR/year for infrastructure - external audit ~3 k EUR

When

When planning changes or preparing for audits. The line without measurable desired position is not complete - you cannot tell when the gap is closed.

References

IIBA BABOK v3 (6.1 Analyze Current State, 6.2 Define Future State, 6.4 Define Change Strategy), ISO/IEC 27003:2017.

NIS2 compliance

Controls shall be compared with points (a) to (j) of Article 21 (2) of the NIS2. Maximum penalty: for essential structures 10 M EUR or 2%, for important 7 M EUR or 1,4% of annual turnover - the higher of the amounts.

Abbreviations

Abbreviations used in the Roadmap: the original name and what it means.

SDLC
Software Development Life Cycle - the life cycle of software development.
BABOK / IIBA
Business Analysis Body of Knowledge / International Institute of Business Analysis - business analysis knowledge and its publisher.
MoSCoW
Must, Should, Could, Won't - priority method: mandatory, preferably possible, this time no.
INVEST
Independent, Negotiable, Valuable, Estimable, Small, Testable - signs of a good user.
NFR
Non-Functional Requirement - non-functional requirement - how good (speed, safety, availability).
BPMN
Business Process Model and Notation - business process chart standard.
UML / OMG
Unified Modeling Language / Object Management Group - the language of modelling and the organisation that maintains it.
DSDM / AgilePM
Dynamic Systems Development Method - Agile project method from which MoSCOW comes.
PMBOK / PMI
Project Management Body of Knowledge / Project Management Institute - the project management knowledge pool.
ASVS
Application Security Verification Standard - the safety requirements to be checked by OWASP catalogue.
SSDF
Secure Software Development Framework - NIST safe development practices.
RPO
Recovery Point Objective - how much data can be lost in an accident.
VDAR
Vispārīgā datu aizsardzības regula - GDPR in Latvian.
TOTP
Time-based One-Time Password - time-based one-off code (authentifier app).