5.2 Software process models

Process Models

• What it’s saying:
  The way we handle requirements isn’t just something you do at the beginning of a project and forget about.
  Instead, it starts right when the project begins and keeps evolving through the entire life cycle of the project.
• Example:
  Imagine you start building an app today. You might initially say “it should let users log in.” Later, after user feedback, you refine that to “users should log in with either email or phone number.” Requirements keep growing and changing.

• Next point:
  Requirements should be treated just like code:
  They are configuration items.
  Meaning: you track changes to them carefully, you control versions, and you manage them using software configuration management — just like you manage your code.
• Example:
  If you update a requirement (“Add dark mode”), you need to version it and make sure everyone knows about it, just like if you updated a file in your codebase.

• Another point:
  The requirements process needs to fit the specific organization and project.
  Not every project will handle requirements the same way — a tiny startup will do things differently than a huge government project.

• Overall:
  The important activities like elicitation (gathering requirements), analysis (understanding them), specification (writing them clearly), and validation (checking they are right) — they all need to be arranged differently depending on the project’s type and its constraints (like size, complexity, deadlines).

Process Actors

• What’s meant here:
  This section is talking about the people involved in the requirements process — who they are and what they care about.
• Very important point:
  The requirements engineer (or specialist) has to bridge two worlds:
  
• The world of stakeholders (users, customers, etc.)
• The world of software engineering (developers, technical teams)
• It’s like being a translator between non-technical people and technical builders.

• Who are these stakeholders?
  
1. Users:
   People who actually use the software.
   Example: the drivers using a ride-sharing app.
2. Customers:
   People who pay for the software, or represent those users.
   Example: a company paying for custom HR software.
3. Market Analysts:
   If there’s no single customer (like in apps sold to millions), market analysts study the market and act like customers — figuring out what the users want.
4. Regulators:
   In industries like banking or public transport, government or regulatory bodies have rules that the software must follow.
5. Software Engineers:
   Developers also have their interests!
   Example: if a customer asks for a feature that would make code reuse impossible for other projects, engineers have to negotiate and weigh pros and cons.

• Important:
  You cannot fully satisfy everyone.
  The software engineer has to negotiate trade-offs between stakeholders’ wishes, while staying inside limits like budget, technical capability, regulations, and more.
• First Step:
  Before negotiating anything, you must identify all the stakeholders, understand what they want (“analyze the nature of their stake”), and gather their requirements (“elicitation”).

Process Support and Management

• This talks about:
  The resources you need to properly run the requirements process — things like money, people, training, and tools.
• Link to bigger picture:
  It connects to Software Engineering Management: you must plan and manage how you’re going to handle the requirements — not just technically, but also in terms of cost, team skills, tools, and time.

Process Quality and Improvement

• This section focuses on:
  Making sure your requirements process itself is high quality and always improving.
• Why?
  Because the quality of the requirements process hugely affects:
  
• The cost of the project
• The timing (whether the project finishes on time)
• The customer’s satisfaction
• So, what do we do?
  We align the requirements process with industry quality standards and process improvement models (like CMMI or ISO standards).

• Inside this topic:
  
1. Requirements process coverage:
   Make sure the improvement models and standards cover the requirements process too — not just coding or testing.
2. Measurements and benchmarking:
   Measure how well your requirements process is doing (e.g., “How many requirements changed mid-project? How many were wrong?”).
3. Improvement planning and implementation:
   Based on those measurements, plan how to improve the way you gather, write, and manage requirements for the next projects.