Software process and requirements

Software engineering applies disciplined, measurable methods to building and maintaining software. Unlike physical products, software is not manufactured and does not wear out, so its quality depends almost entirely on the process used to develop it. This topic covers what makes software different, the quality attributes we aim for, the main process models, CASE tools, and requirements engineering — how we discover, document, validate and manage what the system must do. Many MCQs ask you to match a process model to a situation.

Key concepts

Software characteristics

• Software is developed (engineered), not manufactured; cost lies in design and development.
• Software does not wear out but it deteriorates due to changes (the "idealised vs actual" failure curve shows spikes after each change).
• Much is still custom-built, though reuse and components are increasing.
• It is intangible, flexible, and complex.

Software quality attributes (e.g. McCall/ISO 25010 ideas): correctness, reliability, efficiency (performance), usability, maintainability, portability, reusability, interoperability, security/integrity, testability, scalability, availability.

Software process models

• Waterfall (basis for others): sequential phases; suitable when requirements are stable.
• V-Model: verification and validation model — each development phase has a matching test phase (requirements ↔ acceptance test, system design ↔ system test, architecture ↔ integration test, module design ↔ unit test). Testing is planned early. Rigid; suits safety-critical, well-understood projects.
• Iterative model: start with a subset of requirements, build, then enhance in repeated cycles; each iteration delivers a working version. Early feedback, risk spread out.
• Prototype model: build a quick working mock-up to clarify unclear requirements; users evaluate and refine it. Throwaway (discarded) vs evolutionary (grows into the product). Best when requirements are vague.
• Agile model: iterative and incremental with short iterations (sprints of about 1–4 weeks), working software over documentation, customer collaboration, responding to change. Methods: Scrum (product owner, scrum master, team; backlog, daily stand-up, sprint review/retrospective), Extreme Programming (pair programming, TDD, continuous integration), Kanban.
• Big Bang model: little or no planning; resources go into coding and requirements are figured out on the way. Simple but high risk; suitable only for small, academic or experimental projects.
• (Also known: incremental, spiral — risk-driven, by Boehm; RAD.)

CASE (computer-aided software engineering): tools that automate software-engineering activities. Upper CASE supports early phases (requirements, analysis, design — e.g. diagram editors), lower CASE supports later phases (code generation, testing, debugging), and integrated CASE (I-CASE) covers the whole life cycle with a shared repository. Benefits: consistency, productivity, documentation.

Requirements

• Functional requirements: what the system must do — services, inputs, outputs, behaviour (e.g. "the system shall generate a monthly bill").
• Non-functional requirements: constraints and qualities — performance, reliability, security, usability, portability; also organisational (standards, delivery) and external (legal, ethical). Often more critical than individual functions: failing one may make the system unusable.
• Domain requirements: from the application domain.
• User requirements: high-level, in natural language and diagrams, for customers and managers.
• System requirements: detailed, precise specifications of functions and constraints, used as a basis for design and possibly the contract.
• Interface specification: precise definition of interactions with other systems — procedural interfaces (APIs), data structures exchanged, and data representations.

The software requirements document (SRS): the official statement of what developers must implement. It should be correct, complete, consistent, unambiguous, verifiable, traceable and modifiable, and should state what, not how. IEEE 830 gave a common structure: introduction (purpose, scope, definitions), overall description, specific requirements, appendices and index.

Requirements engineering process

• Feasibility study: technical, economic, operational (and legal, schedule) feasibility.
• Elicitation and analysis: discover requirements with stakeholders — interviews (open/closed), questionnaires, observation/ethnography, workshops and brainstorming, scenarios and use cases, prototyping. Then classify, prioritise and resolve conflicts.
• Specification: write the SRS.
• Validation: check the requirements really define what the customer wants — reviews, prototyping, test-case generation. Checks: validity, consistency, completeness, realism, verifiability.
• Management: requirements change; manage them with identification, change-management process (analysis, cost of change, implementation) and traceability (source, requirement-to-requirement, requirement-to-design).

High-yield points

• V-model pairs each development phase with a test phase; testing is planned early.
• Prototype model suits unclear requirements (throwaway or evolutionary).
• Big Bang model: almost no planning; only for small or experimental projects.
• Functional = what the system does; non-functional = qualities and constraints.
• The SRS states what, not how.
• Validation: "right product?"; verification: "product right?".

Worked example

Classify for a library system: (a) "A member can reserve a book"; (b) "Search results appear within 2 seconds"; (c) "Passwords are stored encrypted". The librarian cannot describe the screens she wants — which model fits?

1. (a) is a service the system provides → functional.
2. (b) is a performance constraint → non-functional.
3. (c) is a security quality → non-functional.
4. Unclear interface requirements → build a mock-up first → prototype model.

Exam tips

• "Requirements unclear, users want to see something first" → prototype model. "Testing paired with each phase" → V-model. "No planning, small project" → Big Bang. "Frequent change, short sprints" → Agile.
• Software does not wear out; it deteriorates through change.
• Performance, security and reliability are non-functional; a calculation or report is functional.
• Validation asks "are we building the right product?"; verification asks "are we building the product right?".
• Upper CASE = analysis/design; lower CASE = coding/testing.

Exam-style questions

From Calmon's question bank, which has 27 questions on this topic.

1. Which type of requirement specifies constraints such as performance, reliability and security of the system rather than specific functions?

• A. Functional requirement
• B. Non-functional requirement
• C. User requirement
• D. System requirement

Answer: B. Non-functional requirements describe qualities and constraints of the system as a whole (performance, security, usability), whereas functional requirements describe services it must provide.

2. The process to gather the software requirements from client, analyze and document them is known as ___________________.

• A. Feasibility Study
• B. Requirement Gathering
• C. Requirement Engineering
• D. System Requirements Specification

Answer: C. Requirement engineering encompasses gathering, analyzing, and documenting software requirements systematically.

Practise ACtE08 questions →