# Software Engineering: Process, Requirements, Design and Quality > Comprehensive software engineering notes on life-cycle processes, project management, measurement, risk, quality, testing, maintenance, requirements, design, object-oriented analysis and architecture. - Author: Muhammet Ali Köker - Language: en - Canonical: https://alikoker.com.tr/en/software-engineering-process-requirements-design-quality - Translation: https://alikoker.com.tr/yazilim-muhendisligi-surec-gereksinim-tasarim-kalite - Published: 2014-12-14T18:15:00+03:00 - Modified: 2026-07-22T21:15:00+03:00 - Verified: 2026-08-08T15:00:00+03:00 - Type: article I kept these software-engineering notes to connect process models, project management, quality, testing, maintenance, requirements and design rather than study them as isolated definitions. The original course material is preserved, including classical methods that are historically important. Later revisions add DevOps, continuous delivery and updated quality/life-cycle standards where useful, without presenting those later practices as if they were part of the original 2013-2015 course material. ## Unit 1: Introduction to Software Engineering ### Software and software engineering A program is executable logic; a software product also includes data, configuration, interfaces, documentation, deployment artifacts and operational assumptions. Software engineering applies systematic engineering methods to the specification, design, construction, verification, operation and evolution of such systems. The purpose is not bureaucracy. It is to control complexity, change and risk when software is larger or longer-lived than one developer can safely hold in working memory. ### Program, software and hardware Hardware fails through physical mechanisms and aging. Software does not wear out in the same physical sense, but it degrades operationally when changes accumulate, dependencies evolve and assumptions no longer match the environment. Software maintenance is therefore primarily change management, defect correction, adaptation and controlled evolution. ### Software engineer and production environment Writing correct code is only part of engineering work. Production software also requires: - version and configuration control, - build/release repeatability, - testing, - deployment and rollback planning, - observability, - security controls, - capacity and failure analysis, - documentation of interfaces and assumptions. ### Classification of software systems Software can be embedded, real-time, interactive, batch, scientific, information-system, safety/security critical, mobile, distributed or infrastructure software. These categories overlap. The engineering method must follow the dominant risks of the system rather than one universal process template. ### Software crisis and continuing complexity The historical "software crisis" described projects that exceeded cost/schedule, delivered unreliable systems or became impossible to maintain as complexity grew. Modern tools improved languages, automation and infrastructure, but the underlying problem remains: requirements change, interfaces multiply, systems become distributed and human coordination does not scale automatically with code size. ### Main sources of software problems Common causes include: - incomplete or changing requirements, - weak architecture, - uncontrolled dependencies, - underestimated integration effort, - poor testability, - unowned technical debt, - unrealistic schedules, - weak configuration/release discipline, - insufficient feedback from production. ### Error propagation through the life cycle A misunderstood requirement can become a design decision, then code, then test assumptions and eventually operational failure. Detecting a defect earlier usually reduces the cost of correction because fewer dependent artifacts must change. This does not mean every requirement can be frozen early; it means feedback cycles should expose errors before they propagate too far. ### Software development life cycle A generic lifecycle contains: ```text need / concept ↓ requirements ↓ design ↓ implementation ↓ verification and validation ↓ deployment / transition ↓ operation and maintenance ↓ retirement ``` The phases can overlap and iterate. ISO/IEC/IEEE 12207:2026 provides a current common framework for software life-cycle processes; the original course notes were based on earlier lifecycle formulations. ### Development plan A project plan defines scope, deliverables, responsibilities, milestones, resources, risks, quality activities and change/control mechanisms. A plan should be updated from evidence; it is not useful if maintained only as a document detached from actual project state. ### Requirements analysis Requirements describe externally meaningful behavior, constraints and quality properties. They should be traceable to stakeholders and verifiable enough that completion can be evaluated. ### Design Design converts requirements into architecture, components, data structures, interfaces and responsibilities. Good design controls coupling and makes expected change local rather than spreading through the system. ### Testing Testing executes or evaluates the system to find failures and gather evidence about conformance. Tests cannot prove the absence of every defect in a non-trivial program; they sample behaviors according to a designed strategy. ### Maintenance and evolution Maintenance includes corrective, adaptive, perfective and preventive change. A system with poor modularity or test coverage may spend most of its lifecycle cost after initial delivery. ### Process maturity Process maturity means the organization can perform and improve engineering activities predictably. It should not be confused with the number of forms or approvals. A repeatable automated process can be more mature than a document-heavy process that is not followed. ### Process models Different process models organize uncertainty and feedback differently. #### Waterfall A strict waterfall treats stages as mostly sequential. It is easy to explain and can fit domains with stable requirements and formal gates, but it performs poorly when important uncertainty is discovered late. #### V-model The V-model pairs specification/design levels with corresponding verification levels. It emphasizes planning tests against requirements and architecture rather than waiting until implementation is complete. #### Prototyping A prototype reduces uncertainty about interfaces, usability or technical feasibility. A throwaway prototype should not silently become production architecture without re-evaluating quality requirements. #### Fourth-generation/code-generation approaches Historical fourth-generation tools aimed to generate large parts of applications from higher-level models or declarative descriptions. Modern low-code tools, ORM generators, schema compilers and model-based toolchains continue the same idea in different forms. #### Evolutionary and research-oriented development When requirements are uncertain, iterative experiments can reduce technical risk. The important control is to distinguish exploratory code from components that have been hardened for production constraints. #### RAD Rapid Application Development emphasizes short cycles, prototyping and reuse. Speed is valuable only if quality and long-term maintainability are not deferred indefinitely. #### Incremental development An incremental model delivers the system in usable slices. Each increment should preserve architecture and integration discipline; otherwise increments simply accumulate incompatible local solutions. #### Spiral model The spiral model is risk-driven. Each cycle identifies objectives, analyzes risks, develops/validates a solution and plans the next cycle. It is especially useful conceptually when technical risk should determine what to prototype or prove first. #### Agile development Agile approaches emphasize short feedback cycles, working software, collaboration and adaptation. They do not remove architecture, testing or documentation; they move decision-making toward continuous evidence and incremental delivery. #### DevOps and continuous delivery: later update DevOps extends responsibility across development and operations through automation, shared feedback and operational ownership. Continuous integration and delivery reduce batch size between code change and deployable artifact. A high-frequency pipeline is useful only when tests, deployment controls, observability and rollback are reliable enough to keep change risk bounded. ### CASE tools Computer-Aided Software Engineering historically grouped modeling, code generation, documentation and project-support tools. Modern IDEs, CI systems, static analyzers, issue trackers and model/code generators can be understood as a more distributed engineering toolchain. ## Unit 2: Software Project Management ### Purpose Project management coordinates scope, time, cost, people, quality and risk. Software projects are difficult because progress is less physically visible than in many engineering disciplines and because late integration can expose hidden dependencies. ### Project resources Resources include: - people and expertise, - computing environments, - licenses/tools, - test hardware/data, - time, - external suppliers and dependencies. Adding people to a late project can increase coordination and onboarding cost; staffing is not a linear throughput control. ### Team organization Teams need clear ownership and communication paths. Centralized, decentralized and mixed structures have different strengths. Architecture ownership should not mean one person becomes a throughput bottleneck; decisions and interfaces must be documented enough for collective execution. ### Software measurement Direct measures include values such as elapsed time, defect count, build duration and resource consumption. Indirect measures try to represent qualities such as maintainability or complexity. Metrics can distort behavior when treated as targets without context. Lines of code, commit count or ticket closure count are particularly poor measures of individual productivity. ### Function points Function Point Analysis estimates functional size from user-visible inputs, outputs, inquiries, files and interfaces. It was designed to be less language-dependent than LOC. Its value depends on consistent counting and suitable project type; it is not a universal predictor of engineering effort. ### LOC versus FP LOC is objective after code exists but varies with language, generation and style. FP estimates functionality earlier but requires interpretation. Both are proxies, not direct measures of value or complexity. ### Cost estimation Estimation methods include: - expert judgment, - analogy, - Delphi/wideband consensus, - parametric models, - decomposition and bottom-up estimation. An estimate should include uncertainty rather than presenting one precise number as certainty. ### COCOMO COCOMO is a parametric effort-estimation family based on software size and cost drivers. Its historical forms are useful for understanding nonlinear effort growth. Any real use requires calibration to contemporary technology and organization rather than blindly applying old coefficients. ### Putnam-Norden-Rayleigh model The Putnam approach models staffing/effort over time with a Rayleigh-like curve and relates size, effort and schedule. It demonstrates an important principle: aggressively compressing schedule can increase required effort disproportionately. ### Risk management A risk is an uncertain event/condition with potential impact. A useful risk record includes probability, impact, trigger/indicator, owner and response. Risk categories can include: - product size/scope, - business/customer, - process, - technology, - development environment, - staffing, - external dependency. Responses include avoid, reduce/mitigate, transfer/share or accept with contingency. ### Project schedule A schedule should reflect dependency structure, not simply assign arbitrary dates to every task. Gantt charts show task timing. PERT/CPM model precedence and critical paths. The critical path contains activities whose delay can delay completion when there is no available float. ## Unit 3: Software Quality Management and Testing ### Software quality Quality means fitness relative to explicit and implicit requirements. It includes functional correctness but also performance, reliability, security, maintainability and other properties. ISO/IEC 25010:2023 defines a current product-quality model with nine characteristics. This is a later update to the older quality models used in the original notes. ### Quality metrics Metrics should correspond to engineering decisions. Examples include defect escape rate, failure rate, response-time percentiles, resource utilization and code-complexity indicators. ### Halstead metrics Halstead metrics derive values from counts of distinct/total operators and operands. They are historically important quantitative code metrics but should not be treated as direct measures of human cognitive difficulty or quality. ### McCabe cyclomatic complexity Cyclomatic complexity measures independent control-flow paths. For a connected control-flow graph: ```text V(G) = E - N + 2 ``` and for structured code it is also related to the number of decision points plus one. High complexity can indicate testing/maintenance difficulty, but a low number does not guarantee good design. ### Quality assurance and quality control Quality assurance focuses on processes that prevent defects and establish confidence. Quality control evaluates work products and finds nonconformance. Reviews, automated checks and testing can contribute to both depending on context. ### Technical reviews Code/design reviews find defects, spread knowledge and challenge assumptions before deployment. Effective review has a defined scope and should focus on correctness, maintainability and risk rather than personal style preferences. ### Test levels Common levels are: - unit/component, - integration, - system, - acceptance. The boundaries depend on architecture, but each level should have a clear purpose and test oracle. ### Unit testing A unit test exercises a small component under controlled dependencies. Test doubles/drivers/stubs may isolate collaborators, but excessive mocking can test the mock arrangement rather than real behavior. ### Integration testing Integration tests verify component interactions, protocols, database mappings and lifecycle assumptions. Historical top-down integration begins from high-level components with lower stubs; bottom-up integration begins from lower components with drivers. Contemporary systems often combine incremental vertical slices with automated contract/integration tests. ### System and acceptance tests System tests validate end-to-end system behavior against system requirements. Acceptance testing evaluates whether the delivered system is suitable for stakeholder/business use under agreed criteria. ### Debugging Testing reveals a failure; debugging finds and corrects its cause. Reproducing the failure deterministically, narrowing the state difference and validating the correction are separate steps. ### White-box testing White-box techniques use implementation structure. Basis-path testing relates tests to control-flow paths. Loop testing considers zero, one, boundary and repeated iterations according to permitted ranges. Exhaustively covering every path is generally impossible when loops and conditions combine, so coverage is evidence rather than proof. ### Black-box testing Black-box techniques derive tests from externally specified behavior. **Equivalence partitioning** groups inputs expected to behave similarly. **Boundary-value analysis** targets edges where defects are common. **Cause-effect graphs** and **decision tables** model combinations of conditions and resulting actions. ### Test planning A test plan defines scope, environments, data, responsibilities, entry/exit criteria and evidence. Test specifications should identify expected results and preconditions so a passing test means something reproducible. ### Verification and validation Verification asks whether the work product satisfies its specification; validation asks whether the resulting system satisfies its intended use. Both activities should occur throughout the lifecycle. ### Regression testing Regression tests check that existing supported behavior still works after change. A regression suite should be fast and reliable enough to run frequently; flaky tests reduce trust and therefore reduce actual protection. ### Continuous testing: later update Modern CI pipelines execute tests, static analysis and packaging automatically on changes. Production confidence also requires integration, performance, security and deployment verification that may run at different cadences. ## Unit 4: Maintenance and Configuration Management ### Maintenance Maintenance includes: - corrective changes, - adaptive changes, - perfective improvements, - preventive refactoring/hardening. The classification is useful, but one change can belong to more than one category. ### Installation and field support Delivery includes installation, migration, configuration and operational support. A product that works only in the developer environment is not production-ready. ### Maintainability Maintainability improves when modules have clear responsibilities, interfaces are stable, tests cover behavior and operational diagnostics identify failures quickly. ### Reducing maintenance cost Useful practices include: - simple architecture, - controlled dependencies, - readable code, - automated tests, - reproducible builds, - documented data migrations, - compatibility policies, - observability. ### Software configuration A configuration identifies exact versions of source, dependencies, build inputs, deployment parameters and sometimes infrastructure/data schema required to reproduce a system state. ### Configuration management SCM controls: - identification, - versioning, - change control, - status accounting, - audit/release baselines. ### Baseline A baseline is an agreed configuration used as a reference for further change. In modern delivery, signed/versioned build artifacts and immutable releases often play this role. ### Change control Not every change needs a committee, but every production-impacting change needs an accountable path: why it exists, what it changes, how it was verified and how it can be reverted or mitigated. ### Configuration audit and status reporting An audit checks whether delivered artifacts correspond to the declared configuration. Status reporting records which change/version is in which environment and whether required controls have completed. ### Version control Distributed version-control systems make branching/merging inexpensive, but repository history alone is not release management. Builds must still map commits to reproducible artifacts and deployment state. ### Modern configuration chain A contemporary chain can be: ```text source commit ↓ locked dependencies ↓ reproducible build ↓ versioned artifact/container ↓ environment configuration ↓ deployment record ``` Secrets should not be embedded into source or ordinary configuration artifacts. ## Unit 5: Software Requirements Analysis ### Requirements Requirements describe behavior or constraints expected from the system. **Functional requirements** specify what the system does. **Non-functional requirements** specify qualities/constraints such as latency, availability, security, capacity, auditability or portability. A statement such as "the system shall be fast" is not sufficiently verifiable. A requirement should define measurable conditions where the property matters. ### Requirements specification A specification should be correct, consistent, sufficiently complete, unambiguous, traceable and verifiable for its intended use. These are goals; real projects manage uncertainty rather than pretending it does not exist. ### Requirement versus design "The system shall authenticate users" is a requirement. "Use protocol/library X" is usually a design constraint unless a stakeholder/regulation specifically requires it. Separating need from implementation preserves design freedom. ### Traceability Traceability links: ```text stakeholder need -> requirement -> design element -> implementation -> verification evidence ``` This is valuable in regulated or critical systems and also when impact analysis is difficult. ### Studying the existing system Legacy behavior is often an undocumented source of requirements. Existing workflows, database constraints, operational scripts and failure workarounds should be investigated before replacement. ### Elicitation techniques Techniques include interviews, workshops, observation, questionnaires, document analysis, prototypes and analysis of actual production behavior. Stakeholders frequently describe desired solutions rather than underlying needs; elicitation should distinguish the two. ### Data modeling Conceptual data models identify entities, relationships, lifecycle and constraints before physical schema decisions. ### UI prototyping UI prototypes expose workflow and terminology uncertainty early. Visual fidelity should match the question being tested; a low-fidelity workflow prototype is often more informative early than a polished mockup. ### Evaluating the analysis model Check whether every requirement is represented, conflicts are visible, system boundaries are clear and exceptional/error cases are modeled. ### Formal specification Formal methods express requirements using mathematically defined notations. They are valuable when ambiguity or proof obligations justify the cost, particularly in protocols, safety properties and critical algorithms. ### State-oriented notations State machines describe lifecycle transitions. Transition tables make event/state combinations explicit and are effective for protocols and control systems. ### Decision tables Decision tables enumerate combinations of conditions and actions. They help expose missing and contradictory business-rule combinations. ### Petri nets Petri nets model concurrency, synchronization and resource flow through places, transitions and tokens. Reachability and liveness analysis can expose deadlock-like behavior in modeled systems. ### Data-flow analysis Data-flow diagrams model external entities, processes, data stores and flows. They are historically important structured-analysis tools and remain useful when the problem is primarily transformation of information. ### Data dictionary A data dictionary defines names, meanings, structure, units, valid ranges and ownership of shared data elements. Modern API/schema registries and typed contracts continue the same discipline. ## Unit 6: Software Design ### Purpose of design Design decides how responsibilities, state and interfaces will satisfy requirements while controlling change and operational risk. ### Architecture and data design Architecture defines major components, deployment boundaries and interactions. Data design defines ownership, schema, consistency and lifecycle of information. Treating persistent data as an afterthought creates coupling that is difficult to remove later. ### Modularity A module should have a coherent responsibility and a small explicit interface. Modularity is valuable when it reduces the number of components affected by one change. ### Cohesion and coupling High cohesion means related behavior belongs together. Low coupling means modules depend on few stable details of one another. These are design objectives, not absolute numeric properties. ### Abstraction and information hiding Abstraction exposes a useful model; information hiding conceals decisions likely to change. A stable interface should not leak internal storage, protocol or timing details unless callers genuinely need them. ### Structured programming Sequence, selection and iteration provide disciplined control flow. Structured programming historically replaced arbitrary branch-heavy programs and remains a foundation even when modern languages add exceptions, async control and functional constructs. ### Preliminary and detailed design High-level design identifies components and interfaces. Detailed design defines algorithms, state and local contracts. The right amount of detail is what makes independent implementation and verification possible without freezing irrelevant choices. ### Structural design and historical flow transformations Structured-design methods transformed data-flow models into module hierarchies. Their specific notation is historical, but the idea of deriving component boundaries from information flow remains useful. ### Design notations Pseudocode, flowcharts, structure charts, UML diagrams and interface definitions should be used when they make a decision clearer. Producing diagrams with no decision content is not documentation quality. ### User-interface design UI design should account for user tasks, feedback, errors, accessibility, consistency and latency. A technically correct backend can still produce an unusable system if interaction state is ambiguous. ## Unit 7: Object-Oriented Analysis and Design ### Object-oriented approach Objects combine state with operations; classes define families of objects. Encapsulation, inheritance and polymorphism are mechanisms, not goals by themselves. ### Analysis Object-oriented analysis identifies domain concepts, responsibilities and interactions without prematurely deciding every implementation class. Historical Coad-Yourdon and Booch methods influenced later UML-based modeling. ### UML Useful diagrams include: - class diagrams for structural relationships, - sequence diagrams for time-ordered interaction, - state-machine diagrams for lifecycle behavior, - activity diagrams for workflow, - package/component diagrams for dependency/architecture views, - use cases for actor-goal interactions. A UML diagram should answer a question; not every project needs every diagram type. ### CRC cards Class-Responsibility-Collaborator cards are a lightweight technique for discussing what a class owns and whom it must collaborate with. Their value is in design conversation, not the physical card format. ### Relationships Association, aggregation/composition, dependency and inheritance communicate different semantics. Composition expresses ownership/lifetime more strongly than a generic association. ### Concurrency and subsystem design Concurrent objects/components need explicit synchronization and ownership of mutable state. Hiding a lock inside every object does not automatically produce a deadlock-free system; lock ordering and cross-component operations matter. ### Design patterns Patterns name recurring design structures. They are not mandatory templates. A pattern is useful when the forces that motivated it are present; using patterns for their own sake adds indirection. ### SOLID connection Later object-oriented design discussions often use SOLID principles: - single responsibility, - open/closed, - Liskov substitution, - interface segregation, - dependency inversion. They are heuristics for managing change and substitution. They do not override simpler design when the abstraction has no real variability. ### Composition over inheritance Composition often reduces coupling to a base-class implementation and allows behavior to be assembled explicitly. Inheritance remains appropriate for stable substitutable type relationships. ### Limits of object orientation Not every problem is best decomposed into stateful objects. Data-oriented, functional, relational, actor/message and pipeline designs can be better depending on workload and invariants. ## Unit 8: Implementation and Coding Implementation converts design into executable artifacts while preserving interface and quality constraints. ### Development environments and languages Tooling should provide reproducible compiler/runtime versions, diagnostics, tests and build automation. Language selection depends on ecosystem, runtime, performance, safety, platform and maintainability constraints. ### Database systems and libraries A third-party component saves development cost only if its lifecycle, license, security and operational behavior are acceptable. Dependencies are part of the system and must be versioned and monitored. ### Coding style Style exists to make code consistent and reduce cognitive noise. It should prioritize clarity, correctness and automated formatting/static checks over subjective preference. ### Exception/error handling Errors should be represented at the right abstraction level. Low-level exceptions can be translated into domain errors, but diagnostic context should not be destroyed. Recovery is appropriate only when the current layer has enough information to recover correctly. ### Code review Review should examine invariants, boundary behavior, concurrency, security, tests and maintainability. Automatable formatting/lint issues should be handled by tools so human review can focus on reasoning. ## Unit 9: Software Architectures ### Architectural approach Architecture defines system boundaries, data ownership, communication and deployment relationships. Architectural decisions are expensive to reverse when they affect persistence or external contracts. ### Client-server A client requests services from a server. The model says little about physical scale; both can be processes on one host or distributed across networks. ### Two-tier and three-tier A two-tier information system often connects client logic directly to a database/service. Three-tier separates presentation, application/domain logic and data management. The separation can improve deployability and policy control, but extra tiers add latency and operational complexity. ### N-tier and distributed architectures N-tier systems split responsibilities further. Distribution should follow real scaling, isolation or organizational needs. A network call is slower and less reliable than an in-process call and introduces partial failure. ### Web architecture Web applications combine HTTP, browser/client state, application services, caching and persistent storage. Stateless server endpoints can simplify scaling, but sessions and transactions still create state somewhere in the system. ### Historical WAP WAP-era architectures adapted web-style services to constrained mobile devices and networks. Their historical importance is in showing how protocol stacks respond to bandwidth/device constraints; contemporary mobile/web systems use different standards. ### Component-based architecture Components expose defined interfaces and can be developed/deployed/reused with controlled dependencies. Component boundaries should correspond to cohesive behavior, not arbitrary packaging. ### SOA and microservices: later update Service-oriented architecture organizes capabilities behind service contracts. Microservices emphasize independently deployable bounded services, decentralized ownership and operational automation. Splitting a monolith into network services does not automatically improve architecture. It introduces distributed transactions, observability, versioning, retries, latency and deployment complexity. A modular monolith is often the better starting point when independent scaling/deployment is not required. ## Unit 10: CASE, Toolchains and Reengineering ### CASE concept CASE tools historically supported modeling, documentation, code generation and project management. The objective was consistency among engineering artifacts. ### Tool integration Tools add value when information flows between them reliably. A diagramming tool that is never updated after implementation quickly becomes misleading. ### Modern engineering toolchain A contemporary toolchain may integrate: ```text issue/requirement tracking ↓ source control ↓ code review ↓ CI build + tests + static analysis ↓ artifact repository ↓ deployment automation ↓ monitoring / incident feedback ``` Traceability can be maintained through identifiers and immutable build metadata rather than manual duplication. ### Selecting tools Tool choice should consider interoperability, automation, exportability, vendor lock-in, learning cost, security and whether the tool supports the actual engineering process. ### Reverse engineering Reverse engineering recovers design, interfaces or behavior from an existing system. It is necessary when documentation is absent, for migration, compatibility, security analysis and legacy modernization. ### Reengineering Reengineering improves an existing system while preserving required external behavior. It can include refactoring, architecture changes, data migration, language/platform migration and replacement of obsolete components. A safe reengineering process establishes behavioral baselines and migration tests before changing internals. Otherwise "modernization" can destroy undocumented but required behavior. ## Overall Framework The course forms a feedback system rather than a one-way sequence: ```text requirements ↓ design / architecture ↓ implementation ↓ verification ↓ operation ↓ observed failures and new needs └──────────────→ requirements/design ``` Project management controls resources and risk around this loop. Configuration management preserves reproducibility. Quality and testing supply evidence. Maintenance returns operational knowledge to the next design decision. The central engineering lesson is that software quality is an emergent property of the complete lifecycle. Correct source code cannot compensate for an incorrect requirement, an unsafe deployment, an uncontrolled data migration or an architecture whose failure modes were never designed. ## Cite This Work Köker, M. A. (2014). Software Engineering: Process, Requirements, Design and Quality. alikoker.com.tr. https://alikoker.com.tr/en/software-engineering-process-requirements-design-quality - BibTeX: https://alikoker.com.tr/en/software-engineering-process-requirements-design-quality.bib - RIS: https://alikoker.com.tr/en/software-engineering-process-requirements-design-quality.ris - CSL-JSON: https://alikoker.com.tr/en/software-engineering-process-requirements-design-quality.csl.json