Requirements engineering is concerned with systems where a system is a set of components (humans, human procedures, physical devices, software) interacting with each other to meet global objectives.
Why: From a system-as-is we find objectives to create a system-to-be. We start from problems, opportunities and domain knowledge. What: We figure out the requirements, constraints and assumptions. Who: Find out what can meet the requirements. (software-to-be, people, devices, processes, existing software)
Stakeholders can provide requirements, impose constraints or invalidate assumptions. If you fail to consult the correct stakeholders, you may miss out on a set of requirements.
- System-to-be: developers
- Operational area: normal and maintenance operators
- Containing business: customer, sponsor, functional beneficiaries
- Wider environment: subject matter expert, negative stakeholders, financial beneficiaries, political beneficiaries, regulators
A typical process model works by:
- Taking information from stakeholders, existing systems, documents.
- Elicitation & domain analysis Finding functional requirements: what the system can do Finding non-functional requirements: how the software / system should work We could do a background study, interview, workshop, observation / user study, survey / questionnaire, or user forum / feature requests.
- Negotiation & Prioritisation Goals are broken down into sub-goals which may show if there are any conflicts
- Specification & Documentation` Authoring a specification documents, may use different visual tools.